cl command line
Michael Koppelman wrote on Apr 17, 2003
I can't imagine that this an original request, but it sure would be great if the cl app had tcsh/bash style command history, command/filename completion and cursor movement. I hate typing. I'm guessing there is some iraf way of doing this? Has their been discussion on adding this to cl? Gracias, Michael Koppelman http://www.lolife.com/astronomy/
Rick White wrote on Apr 17, 2003
On Thu, 17 Apr 2003, Michael Koppelman wrote: > I can't imagine that this an original request, but it sure would be > great if the cl app had tcsh/bash style command history, > command/filename completion and cursor movement. I hate typing. I'm > guessing there is some iraf way of doing this? Has their been > discussion on adding this to cl? These features are included in PyRAF (http://pyraf.stsci.edu), our Python replacment for the cl. I am personally a big fan of the command/filename completion -- hit tab and it fills in the task name, parameter keyword name, filename, or Python variable name depending on the context. Of course I wrote it so I'm not completely unbiased. Rick White
Perry Greenfield wrote on Apr 17, 2003
> > I can't imagine that this an original request, but it sure would be > great if the cl app had tcsh/bash style command history, > command/filename completion and cursor movement. I hate typing. I'm > guessing there is some iraf way of doing this? Has their been > discussion on adding this to cl? > These features are available in PyRAF, which is a Python-based CL for IRAF. Installing PyRAF does not make the original CL unavailable or require any changes in the IRAF installation. Check pyraf.stsci.edu for details. Perry Greenfield
Mike McFadden wrote on Apr 17, 2003
I am not a user of PyRAF, although this discussion may turn that around.... Strictly IRAF speaking, I found that the 'ehistory' command brings me to a somewhat useable command history interface - although still not as good as bash style. by typing 'ehistory' (or simply 'e') and then enter at the cl> prompt will bring up your last command. Arrow up and down work from there to browse the history - sort of like bash. Careful of commands that span multiple lines - strange things happen on my terminal then. ( 'help ehistory' for more information) -Mike Rick White wrote: > On Thu, 17 Apr 2003, Michael Koppelman wrote: > > > I can't imagine that this an original request, but it sure would be > > great if the cl app had tcsh/bash style command history, > > command/filename completion and cursor movement. I hate typing. I'm > > guessing there is some iraf way of doing this? Has their been > > discussion on adding this to cl? > > These features are included in PyRAF (http://pyraf.stsci.edu), > our Python replacment for the cl. I am personally a big fan > of the command/filename completion -- hit tab and it fills in > the task name, parameter keyword name, filename, or Python > variable name depending on the context. Of course I wrote > it so I'm not completely unbiased. > Rick White -- Michael T. McFadden Research Technician - NASA Nearby Stars (Nstars) Project Dept. of Physics and Astronomy Appalachian State University (828)262-STAR (7827)
Mike Fitzpatrick wrote on Apr 17, 2003
> I can't imagine that this an original request, but it sure would be
> great if the cl app had tcsh/bash style command history,
> command/filename completion and cursor movement. I hate typing. I'm
> guessing there is some iraf way of doing this? Has their been
> discussion on adding this to cl?
This comes up every now and then and it might be interesting to
start a more general discussion of what features the user community would
*really* like to see in IRAF, but for now I'll just append an earlier reply
in the system group that offers some other alternatives on the subject.
Cheers,
-Mike
----------------------------------------------------------------------------
From: fitz@tucana.tuc.noao.edu (Mike Fitzpatrick)
Newsgroups: adass.iraf.system
Subject: CL Arrow-Key History Translations
Date: 5 Dec 2000 00:12:38 -0700
Organization: IRAF Project, National Optical Astronomy Observatories
One of the most common CL-feature requests is the ability to use
the arrow keys to scroll through the CL history in the same way as is done
with tcsh shells. This was implemented directly in the NCL as part of
the SAO R&D package (http://hea-www.harvard.edu/RD) by Eric Mandel, but
it turns out this can largely be done using the existing translations
provided by Xterm and XGterm without modifying the CL at all.
The idea is to use the keymap() translation function to program
various keymap "modes" for the window, each mode can redefine the action
taken by certain keys to provide extra keyboard functionality for a given
task. In this case we can define a "CL mode" which remaps the arrow keys
to implement the arrow-key history mechanism by invoking EHISTORY automat-
ically. As it turns out other modes and translations are needed so the
arrow keys still work as expected when in EPAR and so modes terminate
correctly.
The translations are appended to this posting. To use them do
the following:
1) Save the translations to your .Xdefaults file (or whichever file
defines your user resources).
2) Load the new resources using the command
% xrdb -load ~/.Xdefaults
and start a new XGterm.
3) In the new window, log into the CL and type various commands to
establish a history list.
4) To begin using the arrow keys, type the F2 key to begin CL mode,
the arrow keys can then be used as in tcsh to scroll through the
history.
5) If a problem occurs (i.e. arrows no longer work as expected), or
you leave the CL, type F1 to reset to the default keymap mode.
6) Aside from the arrow keys these translations also redefine the
following function keys in CL mode
F2 toggle the graphics window
F3 invoke the graphics cursor
F4 invoke the image cursor
7) An example mode for remapping the arrows for use with DBX is also
shown, this is invoked with the F3 key from the normal mode.
LIMITATIONS:
- Because these translations affect the text window all the time leaving
the keymap in CL mode will cause the arrow keys to be remapped even
when you're not still in the CL. This means that e.g. the arrows
will no longer scroll the history in the normal unix tcsh. The F1 key
will reset to the default mode in all cases.
- Occassionally you can be left in the ehist mode is you scroll off
the top of the CL history stack, again use F1 to reset.
- The translations here are for use with the 'vi' editor, emacs users
should consult the dev$emacs.ed file for a listing of the keys necessary
for movement with that editor.
- Care should be taken to select keyboard function keys that don't
overlap with functions mapped to them by the window manager (e.g F5 may
be used by the WM to iconify the window and overrides it's use as a
translation here). Modifiers such as Shift, Ctrl or Alt can be used to
work around this.
While not perfect these translations seem to work in most cases. They're
provided "as is" and it's hoped people will follow-up with other more clever
translations or fixes. For more details on translation functions available
see the xterm man page.
-Mike
--------------------------- cut here ------------------------------------
*VT100.Translations: #override \
!<Key>F1: keymap(None) \n\
!<Key>F2: keymap(cl) \n\
!<Key>F3: keymap(dbx)
*VT100.clKeymap.translations: #override \
!<Key>F1: keymap(None) \n\
!<Key>F2: set-visibility(tek,toggle) \n\
!<Key>F3: string("=gcur\n") \n\
!<Key>F4: string("=imcur\n") \n\
!<Key>e: keymap(epar) string("e") \n\
!<Key>Up: keymap(ehist) string("ehist\n") \n\
!<Key>KP_Up: keymap(ehist) string("ehist\n") \n\
None<Key>Down: string(0x0A) keymap(epar) \n\
None<Key>KP_Down: string(0x0A) keymap(epar)
*VT100.ehistKeymap.translations: #override \
<Key>Return: string(0x0D) keymap(cl) \n\
<Key>e: string("e") keymap(ehist) \n\
<Ctrl>c: string(0x0D) keymap(cl) string(0x03) \n\
<Ctrl>u: string(0x0D) keymap(cl) string(0x15) \n\
None<Key>Up: string(0x0B) keymap(ehist) \n\
None<Key>KP_Up: string(0x0B) keymap(ehist) \n\
None<Key>Down: string(0x0A) keymap(ehist) \n\
None<Key>KP_Down: string(0x0A) keymap(ehist) \n\
None<Key>Left: string(0x08) keymap(ehist) \n\
None<Key>KP_Left: string(0x08) keymap(ehist) \n\
None<Key>Right: string(0x0C) keymap(ehist) \n\
None<Key>KP_Right: string(0x0C) keymap(ehist) \n\
!Alt<Key>Left: string(0x02) keymap(ehist) \n\
!Alt<Key>KP_Left: string(0x02) keymap(ehist) \n\
!Alt<Key>Right: string(0x17) keymap(ehist) \n\
!Alt<Key>KP_Right: string(0x17) keymap(ehist)
*VT100.sectionKeymap.translations: #override \
!<Key>Return: string(0x0D) keymap(epar) \n\
!<Key>colon: string(0x3A) keymap(epar) \n\
<Key>bracketright: string(0x5D) keymap(epar)
*VT100.eparKeymap.translations: #override \
!<Key>Return: string(0x0D) keymap(cl) \n\
!<Key>colon: string(0x3A) keymap(cl) \n\
<Key>e: string("e") keymap(epar) \n\
None<Key>Up: string(0x0B) keymap(epar) \n\
None<Key>Down: string(0x0A) keymap(epar) \n\
None<Key>KP_Up: string(0x0B) keymap(epar) \n\
None<Key>KP_Down: string(0x0A) keymap(epar) \n\
!Alt<Key>Left: string(0x02) keymap(epar) \n\
!Alt<Key>KP_Left: string(0x02) keymap(epar) \n\
!Alt<Key>Right: string(0x17) keymap(epar) \n\
!Alt<Key>KP_Right: string(0x17) keymap(epar) \n\
<Key>bracketleft: string(0x5B) keymap(section)
*VT100.dbxKeymap.translations: \
!<Key>F1: keymap(None) \n\
None<Key>Right: string("next\n") \n\
None<Key>Down: string("step\n") \n\
None<Key>Up: string("up\n") \n\
None<Key>Left: string("where\n")
Michael C. B. Ashley wrote on Apr 18, 2003
Hi Mike,
> This comes up every now and then and it might be interesting to
> start a more general discussion of what features the user community would
> *really* like to see in IRAF
- Command-line editing that really works (I use NCL, and it is robust;
the xterm keymap idea, while ingenious, is a kludge that (1) isn't
bullet-proof, and (2) less than 0.1% of users would bother to
install).
- Consistent reliable handling of CNTL-C interruption of scripts.
- The removal of the need to type "flpr; flpr" at mysterious times for
mysterious purposes.
- Error handling. This is the biggest problem with IRAF, in my opinion.
We need a status return codes on all scripts, and all operating system
processes.
- Improved error messages for IRAF scripts.
- Installation via an RPM rather than an interactive shell script.
- The IRAF parameter system has a number of problems, e.g.,
- it makes it difficult to have multiple simultaneously running
scripts under the same username, since the parameter files clash
(I use a temporary directory to get around this).
- new releases often add new parameters, which can then cause
inconsistent behaviour in existing scripts (unless you are
careful to "unlearn" every program you use).
- SPP was a good idea at the time (when FORTRAN-IV was the only standard
you could depend on), but it is now a liability, primarily because it
is usually not a good career move for programmers to become proficient
in it. The GNU C compiler is widespread enough to be a good substitute.
- I think the time has come to drop the cl and move to a good scripting
language such as python or perl. The PyRAF project is on the right track
here.
OK, that's probably enough to go on with! I have an affection for IRAF,
and it would be nice to see it continue to be used for the next several
decades, but if it is to prosper and grow I suspect that some big
decisions will have to be made soon, and some long-held ideas abandoned.
Regards,
Michael
--
Michael Ashley; Dept of Astrophysics, UNSW; www.phys.unsw.edu.au/~mcba
See you in Sydney, IAUXXV 2003 http://www.astronomy2003.com
Anand Sivaramakrishnan wrote on Apr 18, 2003
I did not write Pyraf, and I still endorse it enthusiastically! It is definitely worth learning. What's more, you can start using IRAF from Python, and also use other things (like web queries, phenomenally easy list processing, reading FITS files into local variables in your script and using fast numerical methods on them yourself, apply fft's including FFTW to them, .... I could go on and on and on) in the same script (python script). As an extra bonus of switching to Pyraf is that your CL scripts with errors will report errors at the correct line (where the error occurs) as opposed to 'the line after the last line of the script'. Rick did not pay me for this endorsement, honest! Anand On Thu, 17 Apr 2003, Rick White wrote: > On Thu, 17 Apr 2003, Michael Koppelman wrote: > > > I can't imagine that this an original request, but it sure would be > > great if the cl app had tcsh/bash style command history, > > command/filename completion and cursor movement. I hate typing. I'm > > guessing there is some iraf way of doing this? Has their been > > discussion on adding this to cl? > > These features are included in PyRAF (http://pyraf.stsci.edu), > our Python replacment for the cl. I am personally a big fan > of the command/filename completion -- hit tab and it fills in > the task name, parameter keyword name, filename, or Python > variable name depending on the context. Of course I wrote > it so I'm not completely unbiased. > Rick White > >
Eric Jensen wrote on Apr 18, 2003
Hi, First, let me say that I use IRAF a lot and I think it has a lot of things going for it. Thanks for a very useful software package. But since you asked... > > This comes up every now and then and it might be interesting to > > start a more general discussion of what features the user community would > > *really* like to see in IRAF > > - Command-line editing that really works (I use NCL, and it is robust; > the xterm keymap idea, while ingenious, is a kludge that (1) isn't > bullet-proof, and (2) less than 0.1% of users would bother to > install). I'll second this (both the need for it and the unacceptability of the keymap workaround). I teach a lot of people how to use IRAF (we have only undergraduate students here), and just the lack of a straightforward way to type and edit commands is a big stumbling block for people in becoming comfortable with IRAF. In addition to command-line recall, I'll note a few other, related things: * While ehistory allows one to recall and edit previous commands, it is not easy to edit the *current* command one is typing (e.g. to arrow back and insert a letter you missed typing). * The behavior of the backspace and delete keys is different in ehistory than it is in editing the current command. If one wants to erase the character to the left of the cursor, it's a different key in the current command that it is when in ehistory mode. This is quite confusing. (At least this is the way it is in the default keymapping with many computers I've used.) * Parameter editing suffers from some of the same difficulties as command line editing; no easy way to fix what you've typed, etc. * The xiraf script by Vassilis Charmandaris (http://astrosun.tn.cornell.edu/staff/vassilis/xiraf/) is a great service to the IRAF community, but there's no reason (that I can see) that these things shouldn't just be built into IRAF itself. For example, I can't think of another program that won't even look in a *default* location (i.e. ~/iraf/login.cl) to find its startup file. And is there a good reason not to name the default binary "iraf", or at least to have a symlink from cl to iraf? There are a lot of great things about IRAF - but some of these little things would make using it (and especially *learning* to use it) quite a bit easier. Thanks for listening, Eric P.S. Is ncl no longer being distributed/maintained? I couldn't find it on the SAORD pages. I'll have to try pyraf.
John wrote on Apr 22, 2003
On Thursday 17 April 2003 19:41, you wrote:
Hi,
Could someone remove me from this mailing list?
Thanks,
John
john@cfa.harvard.edu
> > I can't imagine that this an original request, but it sure would be
> > great if the cl app had tcsh/bash style command history,
> > command/filename completion and cursor movement. I hate typing. I'm
> > guessing there is some iraf way of doing this? Has their been
> > discussion on adding this to cl?
>
> This comes up every now and then and it might be interesting to
> start a more general discussion of what features the user community would
> *really* like to see in IRAF, but for now I'll just append an earlier reply
> in the system group that offers some other alternatives on the subject.
>
> Cheers,
> -Mike
>
>
> ---------------------------------------------------------------------------
>- From: fitz@tucana.tuc.noao.edu (Mike Fitzpatrick)
> Newsgroups: adass.iraf.system
> Subject: CL Arrow-Key History Translations
> Date: 5 Dec 2000 00:12:38 -0700
> Organization: IRAF Project, National Optical Astronomy Observatories
>
>
> One of the most common CL-feature requests is the ability to use
> the arrow keys to scroll through the CL history in the same way as is done
> with tcsh shells. This was implemented directly in the NCL as part of
> the SAO R&D package (http://hea-www.harvard.edu/RD) by Eric Mandel, but
> it turns out this can largely be done using the existing translations
> provided by Xterm and XGterm without modifying the CL at all.
>
> The idea is to use the keymap() translation function to program
> various keymap "modes" for the window, each mode can redefine the action
> taken by certain keys to provide extra keyboard functionality for a given
> task. In this case we can define a "CL mode" which remaps the arrow keys
> to implement the arrow-key history mechanism by invoking EHISTORY automat-
> ically. As it turns out other modes and translations are needed so the
> arrow keys still work as expected when in EPAR and so modes terminate
> correctly.
>
> The translations are appended to this posting. To use them do
> the following:
>
> 1) Save the translations to your .Xdefaults file (or whichever file
> defines your user resources).
> 2) Load the new resources using the command
>
> % xrdb -load ~/.Xdefaults
>
> and start a new XGterm.
> 3) In the new window, log into the CL and type various commands to
> establish a history list.
> 4) To begin using the arrow keys, type the F2 key to begin CL mode,
> the arrow keys can then be used as in tcsh to scroll through the
> history.
> 5) If a problem occurs (i.e. arrows no longer work as expected), or
> you leave the CL, type F1 to reset to the default keymap mode.
> 6) Aside from the arrow keys these translations also redefine the
> following function keys in CL mode
> F2 toggle the graphics window
> F3 invoke the graphics cursor
> F4 invoke the image cursor
> 7) An example mode for remapping the arrows for use with DBX is also
> shown, this is invoked with the F3 key from the normal mode.
>
>
> LIMITATIONS:
> - Because these translations affect the text window all the time leaving
> the keymap in CL mode will cause the arrow keys to be remapped even
> when you're not still in the CL. This means that e.g. the arrows
> will no longer scroll the history in the normal unix tcsh. The F1 key
> will reset to the default mode in all cases.
> - Occassionally you can be left in the ehist mode is you scroll off
> the top of the CL history stack, again use F1 to reset.
> - The translations here are for use with the 'vi' editor, emacs users
> should consult the dev$emacs.ed file for a listing of the keys
> necessary for movement with that editor.
> - Care should be taken to select keyboard function keys that don't
> overlap with functions mapped to them by the window manager (e.g F5
> may be used by the WM to iconify the window and overrides it's use as a
> translation here). Modifiers such as Shift, Ctrl or Alt can be used to
> work around this.
>
> While not perfect these translations seem to work in most cases. They're
> provided "as is" and it's hoped people will follow-up with other more
> clever translations or fixes. For more details on translation functions
> available see the xterm man page.
>
>
> -Mike
>
>
> --------------------------- cut here ------------------------------------
>
> *VT100.Translations: #override \
> !<Key>F1: keymap(None) \n\
> !<Key>F2: keymap(cl) \n\
> !<Key>F3: keymap(dbx)
>
> *VT100.clKeymap.translations: #override \
> !<Key>F1: keymap(None) \n\
> !<Key>F2: set-visibility(tek,toggle) \n\
> !<Key>F3: string("=gcur\n") \n\
> !<Key>F4: string("=imcur\n") \n\
> !<Key>e: keymap(epar) string("e") \n\
> !<Key>Up: keymap(ehist) string("ehist\n") \n\
> !<Key>KP_Up: keymap(ehist) string("ehist\n") \n\
> None<Key>Down: string(0x0A) keymap(epar) \n\
> None<Key>KP_Down: string(0x0A) keymap(epar)
>
> *VT100.ehistKeymap.translations: #override \
> <Key>Return: string(0x0D) keymap(cl) \n\
> <Key>e: string("e") keymap(ehist) \n\
> <Ctrl>c: string(0x0D) keymap(cl) string(0x03) \n\
> <Ctrl>u: string(0x0D) keymap(cl) string(0x15) \n\
> None<Key>Up: string(0x0B) keymap(ehist) \n\
> None<Key>KP_Up: string(0x0B) keymap(ehist) \n\
> None<Key>Down: string(0x0A) keymap(ehist) \n\
> None<Key>KP_Down: string(0x0A) keymap(ehist) \n\
> None<Key>Left: string(0x08) keymap(ehist) \n\
> None<Key>KP_Left: string(0x08) keymap(ehist) \n\
> None<Key>Right: string(0x0C) keymap(ehist) \n\
> None<Key>KP_Right: string(0x0C) keymap(ehist) \n\
> !Alt<Key>Left: string(0x02) keymap(ehist) \n\
> !Alt<Key>KP_Left: string(0x02) keymap(ehist) \n\
> !Alt<Key>Right: string(0x17) keymap(ehist) \n\
> !Alt<Key>KP_Right: string(0x17) keymap(ehist)
>
> *VT100.sectionKeymap.translations: #override \
> !<Key>Return: string(0x0D) keymap(epar) \n\
> !<Key>colon: string(0x3A) keymap(epar) \n\
> <Key>bracketright: string(0x5D) keymap(epar)
>
> *VT100.eparKeymap.translations: #override \
> !<Key>Return: string(0x0D) keymap(cl) \n\
> !<Key>colon: string(0x3A) keymap(cl) \n\
> <Key>e: string("e") keymap(epar) \n\
> None<Key>Up: string(0x0B) keymap(epar) \n\
> None<Key>Down: string(0x0A) keymap(epar) \n\
> None<Key>KP_Up: string(0x0B) keymap(epar) \n\
> None<Key>KP_Down: string(0x0A) keymap(epar) \n\
> !Alt<Key>Left: string(0x02) keymap(epar) \n\
> !Alt<Key>KP_Left: string(0x02) keymap(epar) \n\
> !Alt<Key>Right: string(0x17) keymap(epar) \n\
> !Alt<Key>KP_Right: string(0x17) keymap(epar) \n\
> <Key>bracketleft: string(0x5B) keymap(section)
>
> *VT100.dbxKeymap.translations: \
> !<Key>F1: keymap(None) \n\
> None<Key>Right: string("next\n") \n\
> None<Key>Down: string("step\n") \n\
> None<Key>Up: string("up\n") \n\
> None<Key>Left: string("where\n")
R.J. wrote on Apr 22, 2003
The IRAF is very good scientific application, but it was written in rather older procedural paradigm. IMHO the object oriented paradigm would be better for such a big project. Organise "uparm" as SQL object oriented database, allow a user define the virtual functions (let's mention the input(keyboard)/output ones), introducing exceptions, etc. would be perfect. robert
Last post on Apr 22, 2003