Subject: bug#10967: Weird 'du' behavior. Bug in coreutils-8.15 ?

From: Jim Meyering <[email-masked]>
Date: Thu, 08 Mar 2012 12:39:09 +0100

Pádraig Brady wrote:
> On 03/08/2012 10:36 AM, Jim Meyering wrote:
...
>> Subject: [PATCH] du: --one-file-system (-x) ignores non-directory arguments
>
> I find it a bit easier to parse if the summary describes
> the change rather than the bug. So something like:
>
> du: fix -x to include non-directory arguments

Thanks for the quick feedback.

I see your point, but prefer not to use "include", because that
might evoke du's --exclude or --exclude-from options.
How about this?

  du: fix -x: don't ignore non-directory arguments

...
>> * src/du.c (process_file): Don't use the top-level FTS->fts_dev
>> when testing for --one-file-system (-x).  It happens to be valid
>> for directories, but it is always 0 for a non-directory.
>> * tests/du/one-file-system: Add tests for this.
>> * NEWS (Bug fixes): Mention it.
>> Reported by Daniel Stavrovski in http://bugs.gnu.org/10967.
>> Introduced by commit v8.14-95-gcfe1040.
>
> While I can `git show` the above revision format,
> gitk doesn't hyperlink it. Does gitweb auto link the above format?
> I guess they may in future at least?

I much prefer to use the version-including form, v8.14-95-gcfe1040
over the bare-SHA1 form that stock gitk currently highlights, so I
patched gitk to also highlight the more human-friendly form.
Not only is it more readable, but with the version-including form,
there is much less need to specify a commit date, title, etc. that
we have been doing.

I posted the patch, and Junio (the git maintainer) liked it
  http://marc.info/?t=132352993500001&r=1&w=2
so I think we're waiting for sign-off from the gitk maintainer,
whom I've just pinged privately.

Here's what it looks like:
  http://meyering.net/code/gitk/gitk-highlight-git-describe-SHA1.jpg

It would be nicer to highlight the entire string, but that would
have required a more invasive patch.

>> +  sed 's/^[0-9][0-9]*	//' u > out2
>> +  echo f > exp2 || fail=1
>> +  compare exp2 out2 || fail=1
>
> Maybe this is enough?
>
> du $opt f | grep . > /dev/null || fail=1

Technically that is enough to detect the bug, but it would
pass even if du were to print nonsense and exit nonzero.
Since these are the only tests that make du operate on a non-directory,
I prefer to check du's exit status and its precise output.