On 03/02/2011 08:09 AM, Jim Meyering wrote: >> I wonder if the better fix would be to modify the gnulib argv-iter >> module to make argv_iter_init_stream to fail if fileno(fp) is a >> directory, since not all platforms reliably fail with EISDIR when doing >> read() on a directory (some, like BSD, successfully return EOF, and some >> older systems even read raw directory contents). > > That's just what I've done. > Here's a tentative patch, both for du.c and argv-iter.c in gnulib. > A probably-identical change to the du.c part will be required for wc.c. > I'll add tests and update NEWS, too. Yes, that looks nicer for directories. Still, I can't help wonder if the same infloop would happen if we encounter EIO or other (rare) error while reading a non-directory, in which case a variant of Stefan's patch is also needed (even though with Jim's patch, it won't trip for the original case of directories that sparked this thread). > +++ coreutils-8.9-stev/src/du.c 2011-03-02 03:32:04.000000000 +0200 > @@ -926,8 +926,10 @@ > switch (ai_err) > { > case AI_ERR_READ: > - error (0, errno, _("%s: read error"), quote (files_from)); > - continue; > + error (EXIT_FAILURE, errno, _("%s: read error"), > + quote (files_from)); > + ok = false; This line would never be reached - once you call error() with a non-zero first argument, it calls exit(). The question is whether it is ever worth trying to continue after a read error on the files-from argument, or whether bailing out like this is the only sane approach. Or maybe we still need the error(0) to issue the warning and affect final exit status, while making sure we break out of the loop rather than continue to retry a read that will likely fail again, so that we at least print the summary of all files successfully read prior to the read error on the files-from argument. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org