non-zero exit status
2007-12-25 9:25:00
ORIGINAL QUESTION:
Hi, I noticed a very strange thing with csh/tcsh.
% yes|head -1;echo $status
y
status=-2147483635
%
If I use tcsh instead of csh, the status is 141.
But, sh behaves fine:
% sh -e
$ yes|head -1
y
$
The shell doesn't exit, so the return status is zero.
Since yes not in /usr/ucb on Solaris, it can be simulated by
awk 'BEGIN{while(1)print "y"}'. Also, there's nothing wrong with head
command, because head can be simulated by awk '{print;exit 0}' with the
same result.
So I make a conclusion that csh family doesn't like the broken pipe,
while
bourne shell family is ok with it.
This looks like a fairly important porting issue, because sh scripts
will
behave differently ported to csh whenever they test status of previous
command. Does any1 know more about this issue?
Thanks.
Will summarize if there's interest.
Igor
-----------------------------------------------------
Thanks to every1 who replied. The majority of people refered me to a
document "Why CSH programming is considered harmful" available from any
rftm site under comp.unix.shell (rtfm.mit.edu, for example). I was
familar with this document before, and it doesn't mention the bug I found.
The document talks about some csh bugs, which by the way almost all have
been fixed in tcsh. It makes an emphasis on poor design and lack of
programming functionality exhibited by csh. My opinion is that regardless
whether you use csh for scripting or not ( which I don't, by the way), you
should be aware of its bugs because, I bet, more people use csh-clones
than sh-clones as a login shell.
Those who are interested in how I found this bug and the nature of it,
please read on.
What happens is that you have a continuous stream of data going into the
pipe, so once head is done with reading from pipe, the rest is discarded.
That's what csh doesn't like. In fact, csh on HPUX 9.01 explicitely says
"Broken pipe". Now the problem is that the errno for Broken pipe is 32,
so it doesn't explain returns values like 141, or 2^15, or negative 2^31,
which I've seen in different cases. I have shell variable printexitvalue
set in my tcsh setup, that's how I noticed this bahavior.
I reported this problem to Christos Zoulas, the maintainer of tcsh. The
bottom line is, tcsh is a great user shell ( not saying the best, because
I haven't tried all of them ) and it makes sense to try fixing all the
bugs it inherited from csh, and keep working on user enhancements, while
leaving limited programming support and functionality as is.
Igor
Comments
Got something to say?
You must be logged in to post a comment.
