Re: [Bug-tar] [patch v3] Bug / question in tar

[Pavel Raiskup]

Eric Blake:
> On 03/13/2014 12:00 PM, Paul Eggert wrote:
> > On 03/13/2014 10:32 AM, Pavel Raiskup wrote:
> >> Strictly
> >> speaking, GNU Coding Guidelines are talking about program_output_
> > 
> > You're right, and I hadn't noticed that.  How about doing things the way
> > xargs does them, as Eric Blake pointed out?  That seems like a nice
> > compromise.
> 
> Indeed, the xargs example modifies output according to whether stdin was
> a terminal; likewise for the lzip case.  Your patch looks reasonable to
> me (changing behavior solely on whether stdin is hooked to something
> unlikely to be able to provide full binary input, and not on whether
> stdout is a terminal or not).

I would vote for that also ^^.  Throwing simple warning is possible, it
would help a LOT contrary to current situation — so I am not strictly
against it (will send a patch possibly, just need to adjust testcase).

But I would like to convince you once more, Paul.  This is more like
nitpicking but still if that was at lest a little acceptable:  Sometimes
are programmers constructing command arguments within scripts (e.g.
tar $mode $file).  There is easy to come up with mistake.  Making tar fail
in this case would make the diagnosis little bit easier (not mentioning
the forever-hanging disaster as that should really be unlikely).

Marcus wrote:
> Paul Eggert wrote
> > On 03/13/2014 10:32 AM, Pavel Raiskup wrote:
> >> Strictly
> >> speaking, GNU Coding Guidelines are talking about program_output_
> >
> > You're right, and I hadn't noticed that.  How about doing things the 
> > way xargs does them, as Eric Blake pointed out?  That seems like a 
> > nice compromise.
> >
> Just an idea: Restrict the change of output to the case that no "-f" 
> argument is given - i. e. the user did *not* call "tar -f - -x 
> BIGFILE.tar" - perhaps with further options. Combined with a base64 
> decoder as "compressor", the user might supply the archve on the 
> console, get that to work and want to use it.

Marcus, you are still able to 'cat | tar -x -f -'.  I also don't think that
'tar -x' differs from 'tar -x -f -' because the '-f -' is just an
'./configure' time default which may differ from setup to setup (yes, yes,
the default seems to be always '-f -', though).  BTW, from [1]:

  STDIN
    When the f modifier is used with the t or x function letter and the
    pathname is -, the standard input is an archive file formatted as
    specified by pax with the -x ustar option. Otherwise, the standard
    input is not used.

TBH, I don't see much benefits if we let the tar command reading the
terminal input & success..

[1] http://pubs.opengroup.org/onlinepubs/7908799/xcu/tar.html

Pavel