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

[Pádraig Brady]

On 03/08/2012 11:39 AM, Jim Meyering wrote:
> 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

perfect

>>> 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 agree.

> 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.

Hah cool.
Even if you hadn't been proactive enough to do this,
as long as it was technically possible I'd have been
fine to go with the improved references.

> 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.

cheers,
Pádraig