iraf.net

Hi, Mike---I'm helping a friend who has had iraf and X11IRAF installed on his Fedora workstation; I've been told that the person who did the installation used
the "patched" version, etc. xgterm does work, but it does find the app-defaults.
(If I go to make the printing bigger, it says right at the top that there are no app-defaults). But, I've looked, and indeed the app-defaults/XGterm IS sitting
over in /usr/lib/X11/app-defaults.
Any ideas? The permissions match what works on my Mac.thanks,
phil

Hi Phil,A quick guess would be a missing/incomplete XFILESEARCHPATH environment definition telling the system to look in /usr/lib/X11/app-defaults in the first place. Tryirafnet> echo $XFILESEARCHPATH
:/usr/lib/X11/%T/%N%S:/usr/x11R6/lib/X11/%T/%N%S:/usr/local/lib/%T/%N%S:If all your friend got was the 'xgterm.fedora' binary then it wouldn't have included the app-defaults file, this was part of the X11IRAF src/binary distributions and assumed you used the install script/makefile to install it. I believe having the XGterm resource file in the directory where you start the command will also work but I haven't tried it. In the worst case, the definitions in that file can be put in the user .Xdefaults file.Cheers,
-Mike

Hi, Mike---OK, that's gotten me part where there: you are right that XFILESEARCHPATH
is not defined. Now...sorry for the ignorance level of the question, but so where
and how do I define it? I'm going to mention the second problem we're having here, because MAYBE
they're related...I dunno. The graphics window that comes up from our xgterm
seems to be well behaved, until we go into doslit and get to the "identify" portion. At that point you see a comparison spectrum, and you should be able to "m" a line, type in an approximate wavelength, and the full wavelength and id will pop up based upon its matching in linelists$blah. All of that works, except that the overwritting of the text line in the xgterm doesn't happen. Furthermore, after a couple of tries, we then only get smiley faces (I swear I'm not making this up), things like on the line. It is still taking our input, but it's not showing us what we're typing (again, this is purely in the graphics window). Logging all the way out of IRAF and back in doesn't fix this; instead, we've been rebooting (....), although I suspect that just killing the x-session and restarting it would be enough. It's driving us nuts, as you can imagne. Any thoughts?thanks,
phil

In the above, by "smily face" I meant the punctuation semicolon, parenthesis.
(It came out as an "emoticon" though when I actually wrote those symbols...)

Hi Phil,[quote:30d6435576]OK, that's gotten me part where there: you are right that XFILESEARCHPATH is not defined. Now...sorry for the ignorance level of the question, but so where and how do I define it? [/quote:30d6435576]See e.g. http://www.faqs.org/faqs/x-faq/part2/section-22.html for details.[quote:30d6435576]I'm going to mention the second problem we're having here, because MAYBE they're related...I dunno. The graphics window that comes up from our xgterm seems to be well behaved, until we go into doslit and get to the "identify" portion. At that point you see a comparison spectrum, and you should be able to "m" a line, type in an approximate wavelength, and the full wavelength and id will pop up based upon its matching in linelists$blah. All of that works, except that the overwritting of the text line in the xgterm doesn't happen.[/quote:30d6435576]I think this is more likely related to DougMink's post on using identify from commandline scripts than the XFILESEARCHPATH thing. Try the same workaround there to disable the readline interface; otherwise, does it make a difference whether you use an Xterm or an XGterm? Is the garbage string on the normal status line or overwriting the graphics like in the old xterm days? Nothing in the app-defaults file refers to the terminal behavior so I doubt that's the problem.Please let me know what happens, or what other clues you might uncover.Cheers,
-Mike[/quote]

Hi, Mike---OK, I think the business with the environmental variable is clear from the page to which you referred me---we'll give it a shot.I read the Minx thing, and I am dubious---we're not running ecl, and this is just the regular old "doslit" task calling identify. I am suspicious that maybe there was an installation problem with xgterm (I did not do that myself; my friend sub-contracted it out.) I may simply try reinstalling XGterm the usual way and see if that doesn't solve both the app-defaults issue and the graphics window issue. I'll let you know.thanks,
phil

Phil,You're probably right that this is a different problem. Instead of rebooting however you might use the XGterm menu to do a "Full Reset". Do you see just the two characters (semicolon and paren) or does it look more like a full prompt but with garbage characters? Did fixing the app-defaults thing make any sort of difference? What about the 'noreadline' option?It would help if I could see it in person, feel free to send me a sample image, parameter listing, and command sequence to reproduce the problem if you're still having trouble. I assume this is your Mac system?Cheers,
-Mike

Hi, Mike---The app-defaults problem is now solved, but we are still having the same problem with identify in doslit. I tried
cl.ehinit = cl.ehinit // " noreadline"
(being careful to include the space...) it gives me an error message
saying
"unreocgnized ehistory set-option "noredline noreadline...." etc.This is not on my system, but that of Wes Lockwood's---he's running Fedora, and had Len Bright install the system, including xgterm.I just watched again. If you do an "m" you get the normal line, giving the x and INDEF value. If you then type in the approximate wavelength what SHOULD happen is that it should erase and rewrite that line with the full value it has pulled out of the file. What's happening today (anyway) is that the line just goes blank. Similarly if you do a "." to see what the nearest line is near the cursor, the line stays blank. We can live with this, but it is very weird---never saw a system that misbehaved like this, which is why I think maybe something funny happened
on the installation.thanks,
phil