I've got some experience with bash, ksh, and the like, but the sysadmin has stuck many of us with tcsh instead. I try to perform a command such as:

find / -name foo -print

knowing full well I will get errors on some directories. Of course, in bash I can redirect diagnostic output with >>/dev/null and eliminate the noise. Trying to do that in tcsh, though, fails miserably. From what I can see, I should type

find / -name foo -print >/dev/tty >&/dev/null

but when I do that, the command gets word-broken into

find / -name foo -print > /dev/tty > & /dev/null

which tcsh doesn't want.

I realize I can simply /bin/bash -c "find...", but I'd like to know what I'm doing wrong with tcsh.

It is listed as "ambiguous redirection".

You can get around that putting the initial redirection in parenthises:

The reason this works is that the command "(...) >&/dev/null" redirects both stdout and stderr to /dev/null.
The enclosed command "find / -name foo -print >/dev/tty" then redirects stdout to /dev/tty. The evaluation on the command is from outer grouping () to inner, so the >& is evaluated before the inner command - thus disambiguating the > and the >&.

In my opinion, it is a stupid parser that doesn't tokenize > differently from the >& symbols. But this happens due to a single character token handling - thus when it sees ">" it uses the next character to identify whether it is stdout, or both stdout and stderr. When it sees a following ">&" it does detect that stdout has already been redirected... thus causing an "ambigeous" redirection since ">&" calls for both stdout and stderr to be redirected.

This situation could STILL be handled - if it allowed the ">&" token to appear first (redirecting both stdout and stderr), then allow for redirecting stdout.

This is the same problem that csh has (which is where tcsh is derived).

1 members found this post helpful.