(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