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