iraf.net

(copied to gemprog as related to a problem discussed there - sorry I guess
that means some people get two copies)The following seems to be an example of inconsistent handling of pipes in
IRAF for non-intrinsic (ie external shell) commands. In the enclosed tar
file are four scripts. All four search a file for some text. Two use
grep and two use match. For each command, one task has parentheses around
the grep/match argument, and the other doesn't.The file test.cl defines all four as tasks and calls them on test data.If the contents of test.cl are typed into the cl prompt (eg cut+paste)
then all four tasks work.But if, instead, I type
cl < test.cl
then *both* grep tasks hang until Ctrl-D is pressed (twice for test.cl).So the grep in
type (name) | grep (text)
is apparently connected to the user input (tty stream) rather than the
output from the pervious command when the grep occurs in a task which is
itself invoked from a sequence of cl commands in a file as in
cl < some-file.cl(And the issue of parentheses and command/function mode is apparently a
red herring in this case).Andrew--
` __ _ __ ___ ___| |_____ work web site: http://www.ctio.noao.edu/~andrew
/ _` / _/ _ \/ _ \ / / -_) personal web site: http://www.acooke.org/andrew
\__,_\__\___/\___/_\_\___| list: http://www.acooke.org/andrew/compute.html

(doing reply to all, which is including an alias i'm not familiar with -
hope this is ok).Rob Seaman said:
> Hi Andrew,
>
>> But if, instead, I type
>> cl < test.cl
>> then *both* grep tasks hang until Ctrl-D is pressed (twice for
>> test.cl).
>>
>> So the grep in
>> type (name) | grep (text)
>> is apparently connected to the user input (tty stream) rather than the
>> output from the pervious command when the grep occurs in a task which
>> is
>> itself invoked from a sequence of cl commands in a file as in
>> cl < some-file.cl
>
> Ok. I guess the question is why are you choosing to execute a script
> with
> a redirection command like "cl < test.cl"? Under what circumstances
> would
> this be preferred to declaring "task $test = <path>/test.cl" and typing
> "test"?in this case, because i was trying to demonstrate the problem. )in general, i don't, which is why i didn't see this until i got a call on
the batphone while in santiago. but it is something gemini people do.
they put all the iraf commands for reducing the current data set in a
file, then use "cl < file". so they edit using an editor rather than the
cl, for example (i do this too, but cut+paste from the editor to the cl).so the file contents are considered more as "the session" than "a task",
if you see what i mean (i'm not saying this is a good readon not to
declare them as a task, just trying to explain why i think people don't).> As far as the misbehavior, you appear to have identified an interesting
> issue, but I can't say I'm surprised that IRAF has issues with scripts
> calling
> other scripts. Just think of the textual calisthenics that are
> sometimes
> necessary to pass arguments through a couple of layers of shell scripts
> while
> protecting the user's intent from various obscure Unix features like
> argument
> substitution, filename expansion and path ambiguities (to name just a
> few
> features).
>
> Bottom line - is the issue you have outlined interfering with getting
> the
> job done?no, because i changed "grep" to "match". i sent this to the iraf email
address because i thought it was a possible bug you should know about, and
copied it to gemprog just for background info,it's possible there will be similar problems with other commands - there
are no occurence of "grep" or "ls" in the gnirs package (or in any gemini
package i have on disk, apart from gemlocal).> The IRAF CL is a task based interpreter. This issue wouldn't even be
> mentioned
> for compiled SPP tasks. The declaration of CL scripts should typically
> be
> treated with the same level of care as is used to declare SPP tasks.
>
> All that said, I could imagine expanding the search space associated
> with
> characterizing this foreign task behavior. What happens with "type
> test.cl | cl"?cl> test.cl | cl
ERROR: package `test' not found
cl> ./test.cl | cl
**: ./test.cl | cl
^
ERROR: syntax error> What happens if the greps are explicitly passed to Unix with "!grep"
> escapes?** Syntax error, line 5
**: type (name) | !grep text
^
** Syntax error, line 5
**: type (name) | !grep text
^
(which is odd, as the second task is ...!grep (text) with parentheses.)andrew--
` __ _ __ ___ ___| |_____ work web site: http://www.ctio.noao.edu/~andrew
/ _` / _/ _ \/ _ \ / / -_) personal web site: http://www.acooke.org/andrew
\__,_\__\___/\___/_\_\___| list: http://www.acooke.org/andrew/compute.html