NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/46021: xargs should keep still



The following reply was made to PR bin/46021; it has been noted by GNATS.

From: jklowden%schemamania.org@localhost
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/46021: xargs should keep still
Date: Tue, 14 Feb 2012 11:59:17 -0500

 On Tue, Feb 14, 2012 at 07:25:02AM +0000, David Holland wrote:
 > The following reply was made to PR bin/46021; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: bin/46021: xargs should keep still
 > Date: Tue, 14 Feb 2012 07:20:15 +0000
 > 
 >  On Tue, Feb 14, 2012 at 04:50:00AM +0000, 
 > jklowden%schemamania.org@localhost wrote:
 >   >  xargs writes error messages to standard error if the utility 
 >   >  it's executing exits with an error or on a signal.  E.g.:
 >   >  
 >   >  $ find /usr | xargs ls | head -1
 >   >  /usr/X11R7/bin/X
 >   >  xargs: ls terminated by SIGPIPE
 >   >  
 >   >  As the above example shows, the message is unwelcome and unnecessary.  
 >   > [...]
 >  
 >  I don't agree with your reasoning. Let's consider a similar and not
 >  uncommon case:
 >  
 >  First, create a program that always exits with a signal:
 
 I have a better answer, see below, but I have to admit being amused at 
beginning
 with a "not uncommon" case by writing it.  :-)
 
 >      % find /usr/include | ./die
 >      Segmentation fault
 >      % find /usr/include | ./die | cat
 >      Segmentation fault 
 >      % find /usr/include | xargs ./die 
 >      xargs: ./die terminated by SIGSEGV
 >      % find /usr/include | xargs ./die | cat
 >      xargs: ./die terminated by SIGSEGV
 >      % 
 >  
 >  xargs
 >  doesn't print the same message, but it's equivalent and printed in the
 >  same circumstances.
 
 No, definitely not.  xargs interpreted the signal and printed a message. 
 It swallowed the signal, preventing the shell from seeing it.  In
 the last example, xargs littered the terminal via standard error, but cat
 returned normally (or would, if it ever got started).  
 
 Instead, if you feel it's important to mimic a pipe as precisely as possible 
 (I don't.  I just don't want to see xargs messages, ever.) then xargs 
 should propagate the signal.  If it did that, all four of your examples would
 produce the same "Segmentation fault" message, and mine would produce none at
 all.  
 
 I am prepared to modify my patch in that way, but it will affect how 
 xargs returns when its child is signalled.  
 
 --jkl
 


Home | Main Index | Thread Index | Old Index