iraf.net

I've just installed IRAF 2.14 on my MacBook Pro using Marcos Huerta's pre-packaged Mac OS X installer version. Everything seemed to have gone well after an install and a mkiraf: IRAF ran as before, albeit with a new splash screen. However, I've noticed a problem with imedit, which is one the programs to have been revised. Trying to run it ended up in a failure with the parameter 'minvalue' apparently missing. Indeed, it wasn't in the parameter file when I ran imedit. So I did another mkiraf and reinitialised my uparm; still no joy. Finally, I checked imedit.par in /iraf/iraf/pkg/system/images/tv and there was no mention of minvalue or maxvalue in there either, despite the new help page for imedit in 2.14. I have subsequently checked inside the 2.14 as.pcix.gen source and the imedit.par appears to be without those values too.To fix things, I edited in a minvalue and maxvalue into imedit.par:minvalue,r,h,INDEF,,,Minimum value to modify
maxvalue,r,h,INDEF,,,Maximum value to modifyand this seemed to work.I appear to be in business, but unless I'm mistaken (which is always possible when installing a new IRAF, doing a new mkiraf, etc.), there seems to be a bug in the distributed imedit.par.best wishes,
Markp.s. In passing, the ecl + xgterm combination seems to be behaving oddly in 2.14: it completely hangs if I use cntrl-Z, rather than cntrl-D. I swear I had cntrl-Z mapped to (e.g.) exit from epar properly, but it's broken now. Any suggestions?

Hi Mark,Thanks for catching that. Indeed the parameter source file is missing the 'minvalue' and 'maxvalue' definitions and your recommended additions appear correct. I'll make a note that refers people to this thread. For the record, the file to be edited is images$tv/imedit.parAs for your second point, it sounds as if Ctrl-Z is now the suspend character instead of EOF. Do you get the unix prompt back or just no response? Epar/Ehist behavior is controlled by the character codes defined based on the 'editor' you've set, but both Ctrl-D and Ctrl-Z should do an EXIT_UPDATE for epar regardless of whether you're using emacs or vi. The other things to check is the terminal settings at the unix level, e.g. a 'stty -a' command at the host prompt. Check the settings of the 'eof' and 'susp' characters and look for/adjust their settings with a stty/tset command in your .login file. Cheers,
-Mike

Thanks, Mike: glad I wasn't missing something obvious re: the apparently broken imedit.par file.As for the Ctrl-Z / Ctrl-D dilemma, it goes as follows:If I load a straight xgterm under X11, stty -a shows that under my setup, EOF is ^Z, while SUSP is ^X. Typing ^Z at the command line does nothing bad and the xgterm works fine.If I then type "ecl" in that xgterm, ^Z in IRAF works as EOF just fine: no problems.However, the way I usually invoke IRAF is from a pre-cooked command-line under the Applications menu item of OS X's X11 (for reference, I'm running 10.4.10). That line is:/usr/local/bin/xgterm -e /usr/local/bin/ecl
(with some additional stuff to set the window size, font, etc.)When I do that, IRAF loads and the terminal is fine: I can do an epar imedit, for example. But if I try to exit from that with a ^Z, the whole xgterm locks up: I get no response at all, and can't even close the window with the red button in the top left corner. Only thing that works is to kill the main process. If I go back to the original non-IRAF xgterm (in which ^Z worked fine when I typed "cl") and then type:xgterm -e ecl &I get IRAF up in a new xgterm, but ^Z hangs it again. Note that ecl in usr/local/bin is a link to /iraf/iraf/unix/hlib/ecl.csh, which is turn a link to cl.csh: these all appear to be 2.14 versions. My editor in IRAF is vi which is in fact an alias to vim, but I don't change anything to do with ^Z/^D in my .vimrc.I'm completely flummoxed at this point ... Thanks in advance for any suggestions you might have.Best wishes,
Mark

Quick thought: Try launching with "xgterm -ls -e ...." to force a login shell (or set the 'loginShell' resource to 'true'). If you're remapping your keys with a .login file it may not be read if it's just a 'norma' shell being created. You can also try a "cl> !stty -a" from inside IRAF to see if you've got the expected key settings.-Mike

Hmmm ... !stty -a from within IRAF (launched the way that ^Z normally breaks) shows that ^Z is EOF, as expected. But then if I try and use ^Z, everything works fine, as if I'd been having a bad dream :`(But no, it's back. If I open IRAF my "normal" way and immediately do a ^Z, nothing happens. I mean nothing: the cursor stays put. I would usually expect the line about "use logout to log out of the CL", but nothing. However, it hasn't locked: if I hit return, I get control. If I then type !stty -a and _then_ do a ^Z, I do get the logout message.If I repeat this exercise with a new xgterm+IRAF and go straight into an epar, then ^Z locks things up as before. But if I execute a valid command first (such as the !stty -a or just a simple "ls"), then ^Z works as hoped.Weirder and weirder. Mark

I think I can reproduce the problem and have a partial explanation: When you use the '-e' flag the named command is executed in a shell by the xterm/xgterm process. The 'cl' command is actually a script (C-shell) that runs the actual CL binary using an 'exec' statement, meaning the cl.e binary replaces the parent shell. At this point the cl.e is running as the xterm/xgterm process but the suspend key doean't work because there is no parent shell to drop back into, and so it is ignored. Use of the '-ls' flag to create a login shell apparent'y isn't poertable and works with some shells (bash) but not others (tcsh).I couldn't find a way to work around this easily. Neither could I find a way to reset the default setting of Ctrl-Z as the suspend character when using the '-e' flag. Note this isn't specific to xgterm/ecl, it's a general property of xterm and shells.Cheers,
-Mike