Eric Snyder asks why "<<" processing is broken for GCG commands on
Unix. The answer relates to the fact that each GCG command is invoked
through an alias that turns off globbing and executes in a subshell.
This alias is provided to prevent the shell from processing shell
metacharacters such as '*', which are used by the GCG package to specify
sequences.
For example, here is how the alias for translate is defined:
csh> alias translate
( set noglob; $GCGUTILDIR/translate !* )
The "<<" business doesn't work for commands executed in a subshell,
though. There is a workaround: prefixing a command line with a
backslash suppresses alias processing. Since the GCG programs are in
the $path, the shell is able to find and execute them even without the
alias. Without the alias, the command does not execute in a subshell,
and processing of inline data is enabled.
A minor downside of suppressing the alias processing is that globbing
is left on for the execution of that command, which can interfere with
the wildcard specification of sequences. But, the globbing is only
applied to command line arguments not to the stream of inline data.
So, for example,
csh> \translate << +
file_name
100
200
No
Yes
W
+
works as expected. And
csh> \fetch << +
ba:aa*
+
works as expected, because the '*' shell metacharacter in the sequence
specification is in the inline data, not on the command line.
But if one types
csh> \fetch ba:aa* << +
+
one gets following diagnostic from the shell:
fetch: No match.
Now, that's a pretty silly command line to type, so the simple answer here
is that you can generally work around the alias by using a leading backslash
on your command line in those cases where you wish to present inline data
to workaround commands that don't take a command line.
Hope this helps.
-Scott Rose
