[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8154: du: issue with `--files0-from=DIR'
From: |
Jim Meyering |
Subject: |
bug#8154: du: issue with `--files0-from=DIR' |
Date: |
Wed, 02 Mar 2011 20:25:12 +0100 |
Eric Blake wrote:
> On 03/02/2011 10:10 AM, Paul Eggert wrote:
>> On 03/02/2011 07:09 AM, Jim Meyering wrote:
>>> - struct argv_iterator *ai = malloc (sizeof *ai);
>>> + struct argv_iterator *ai;
>>> + struct stat st;
>>> +
>>> + if (fstat (fileno (fp),&st) == 0&& S_ISDIR (st.st_mode))
>>> + {
>>> + errno = EISDIR;
>>> + return NULL;
>>> + }
>>> +
>>> + ai = malloc (sizeof *ai);
>>
>> My kneejerk reaction is that this part of the patch
>> should not be needed (though other fixes obviously are).
>> There are lots of reasons that the stream could fail:
>> why check for directories specially?
>
> Because other GNU apps do so? For example, POSIX requires that input
> files to m4 must be text files. If you do 'm4 dir/', you are therefore
That's fine for m4, but the --files0-from argument
is a file containing NUL-delimited file names: not a text file.
And obviously not covered by POSIX, besides.
However, my primary motivation was this: if we special-case
directories, should we also special-case char- and block-devices?
That seems inappropriate.
> violating POSIX, because dir/ is not a text file. However, I've chosen
> to make m4 uniformly fail with EISDIR on opening the file, rather than
> deal with the vaguaries of different platforms (some forbid
> fopen("dir/"), although that is in itself a POSIX violation; most get
> past the fopen(), but then it's arbitrary whether the fread() sees EOF,
> reads garbage, or fails with EISDIR). See:
> http://lists.gnu.org/archive/html/m4-patches/2008-09/msg00004.html
> http://git.savannah.gnu.org/cgit/m4.git/commit?id=eed62f0d
>
>> Just let the
>> stream fail in the way that it normally would; this
>> keeps the code smaller and simpler. On an ancient
>> host where "cat dir/" works, "du --files0-from=dir/"
>> should not arbitrarily fail.
>
> Yes, the code would be simpler by letting the directory do what it
> normally does (be that nothing, error, or raw data), but in the case of
> raw data, acting on that garbage is likely to lead to a host of other
> error messages.
- bug#8154: du: issue with `--files0-from=DIR', (continued)
- bug#8154: du: issue with `--files0-from=DIR', Jim Meyering, 2011/03/02
- bug#8154: du: issue with `--files0-from=DIR', Jim Meyering, 2011/03/02
- bug#8154: du: issue with `--files0-from=DIR', Jim Meyering, 2011/03/03
- bug#8154: du: issue with `--files0-from=DIR', Eric Blake, 2011/03/02
- bug#8154: du: issue with `--files0-from=DIR',
Jim Meyering <=
bug#8154: du: issue with `--files0-from=DIR', Jim Meyering, 2011/03/02
bug#8154: du: issue with `--files0-from=DIR', Pádraig Brady, 2011/03/02