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
