when I issued the following command in tcsh or sh

find . -name "S*" | xargs cat | head -1

it said
xargs child killed with signal 13

but why another command (below) is working ?
find . -name "S*" | xargs cat | wc -l
1030

Thanks

John
Toronto

Nicholas Dronen wrote in message news:...
> John wrote:
> > when I issued the following command in tcsh or sh
>
> > find . -name "S*" | xargs cat | head -1
>
> > it said
> > xargs child killed with signal 13
>
> > but why another command (below) is working ?
> > find . -name "S*" | xargs cat | wc -l
> > 1030
>
> Signal 13 is SIGPIPE, which means that a process
> tried to write to a pipe (or socket) the other end
> of which is already closed.
>
> In this case, 'head -1' reads one line from stdin,
> writes it to stdout, and exits, closing the read
> end of the pipe in the process. When cat tries
> to write to stdout (the write end of the pipe),
> it receives a SIGPIPE and goes bye-bye.
>
> The command pipeline using 'wc -l' doesn't behave
> this way because wc reads all of the data from
> stdin, so cat all the data written by cat is
> to a descriptor with an open "read end."
>
> Regards,
>
> Nicholas


But how come
cat file | head -1
is working properly?

Thanks again

John

John wrote:
> Nicholas Dronen wrote in message news:...
>> John wrote:
>> > when I issued the following command in tcsh or sh
>>
>> > find . -name "S*" | xargs cat | head -1
>>
>> > it said
>> > xargs child killed with signal 13
>>
>> > but why another command (below) is working ?
>> > find . -name "S*" | xargs cat | wc -l
>> > 1030

[ snip ]

>> In this case, 'head -1' reads one line from stdin,
>> writes it to stdout, and exits, closing the read
>> end of the pipe in the process. When cat tries
>> to write to stdout (the write end of the pipe),
>> it receives a SIGPIPE and goes bye-bye.

[ snip ]

> But how come
> cat file | head -1
> is working properly?

Cat is killed with a SIGPIPE in both versions of that
shell pipeline. In your first example, *xargs* reports
that its child process, cat, has been killed by a SIGPIPE.
It does this because it's responsible for creating the
cat process in the first place. It's being a good citizen
by telling you this. This also proves that cat does
not trap SIGPIPE.

In your second example, cat receives a SIGPIPE, too.
But since the signal's not trapped it can't report
this fact. When the untrapped signal is delivered
to the process, it is only to terminate it.

In the case of cat, it would never make sense for it
to report that it died of a SIGPIPE. If the read end
of stdout is closed, the same can probably be said of
the read end of stderr. So why bother trapping a signal
(which doesn't cause a core dump, in case you're wondering)
when you probaby can't tell anyone about it and, more
to the point, when it's no big deal anyway. Unless of
course you're using cat(1), Enterprise Edition Jan. 1,
2003, SP 42. That would change everything. :-)

Does that help?

Regards,

Nicholas

--
Please do not reply to USENET posts, at least to mine, by email.

Nicholas Dronen wrote in message news:...
> John wrote:
> > Nicholas Dronen wrote in message news:...
> >> John wrote:
> >> > when I issued the following command in tcsh or sh
>
> >> > find . -name "S*" | xargs cat | head -1
>
> >> > it said
> >> > xargs child killed with signal 13
>
> >> > but why another command (below) is working ?
> >> > find . -name "S*" | xargs cat | wc -l
> >> > 1030
>
> [ snip ]
>
> >> In this case, 'head -1' reads one line from stdin,
> >> writes it to stdout, and exits, closing the read
> >> end of the pipe in the process. When cat tries
> >> to write to stdout (the write end of the pipe),
> >> it receives a SIGPIPE and goes bye-bye.
>
> [ snip ]
>
> > But how come
> > cat file | head -1
> > is working properly?
>
> Cat is killed with a SIGPIPE in both versions of that
> shell pipeline. In your first example, *xargs* reports
> that its child process, cat, has been killed by a SIGPIPE.
> It does this because it's responsible for creating the
> cat process in the first place. It's being a good citizen
> by telling you this. This also proves that cat does
> not trap SIGPIPE.
>
> In your second example, cat receives a SIGPIPE, too.
> But since the signal's not trapped it can't report
> this fact. When the untrapped signal is delivered
> to the process, it is only to terminate it.
>
> In the case of cat, it would never make sense for it
> to report that it died of a SIGPIPE. If the read end
> of stdout is closed, the same can probably be said of
> the read end of stderr. So why bother trapping a signal
> (which doesn't cause a core dump, in case you're wondering)
> when you probaby can't tell anyone about it and, more
> to the point, when it's no big deal anyway. Unless of
> course you're using cat(1), Enterprise Edition Jan. 1,
> 2003, SP 42. That would change everything. :-)
>
> Does that help?
>
> Regards,
>
> Nicholas

That help much. Thanks you so much Nicholas.

What I'm wondering now is how I know what commands attempt to report
closing signal, like xargs does?


Best Regards

John
Toronto

John wrote:

[ snip ]

> That help much. Thanks you so much Nicholas.

> What I'm wondering now is how I know what commands attempt to report
> closing signal, like xargs does?

Any command that does a wait4(2) and uses the macros
WIFSIGNALED and WTERMSIG to tell whether its child
process died because of an untrapped signal and to
get the signal number, respectively.

Regards,

Nicholas

--
Please do not reply to USENET posts, at least to mine, by email.

In article ,
John wrote:
...
>But how come
>cat file | head -1
>is working properly?

The thing you have to understand is that all of this is a function of the
caller (i.e., the "parent process", usually the/a shell), not of the called
program. It is up to the caller to call (some version of) the wait()
system call and report on the results.

So, the point is that it is a function of what shell you are using, not
what command you are running. Also, you should be checking return codes;
if a program exits because of a signal, the return code will be
128+theSignalNumeber. Observe:

%) cat largeFile | head -1;echo $status
lineoftext
141
%) sh -c '{ cat largeFile;echo $? >&2;} | head -1'
lineoftext
Broken Pipe
141
%) ksh -c '{ cat largeFile;echo $? >&2;} | head -1'
lineoftext
141
%)

This is under Solaris with tcsh, sh, and ksh, respectively. Note the
differing behavior.

P.S. Note also that (t)csh returns the error code directly (of the first
thing in the pipeline, unlike the sh-ish shells, which require gymnastics
to get that return code).

On 15 Dec 2002 06:28:29 GMT,
Nicholas Dronen wrote:


>In your second example, cat receives a SIGPIPE, too.
>But since the signal's not trapped it can't report
>this fact. When the untrapped signal is delivered
>to the process, it is only to terminate it.


It is more that the shell only reports the exit status of the
last command in a pipeline, thus when you cat something into
a pipe the exit status of the cat command is lost.



Villy