Paul Eggert <[EMAIL PROTECTED]> wrote: > "Steve Ward" <[EMAIL PROTECTED]> writes: > >> The following commands give different results: >> du --bytes --human-readable foo.txt >> du --human-readable --bytes foo.txt > > --bytes is equivalent to --apparent-size --block-size=1; this is --documented. > --human-readable is equivalent to --block-size=human-readable; this is > --not documented, which is a documentation bug. The later implicit > ----block-size option wins, which explains the behavior you observe. > > I also dislike it when option order affects behavior. Perhaps "du" > should complain about inconsistent options like that?
That sounds like it'd be an improvement, and I'm willing to try it, if someone else does the work :-) However, we'll have to be prepared for some flak, since people with aliases like "du='du -k'" would start getting a warning whenever they use e.g., "du -h". Maybe it'd be palatable with a few strategic exceptions. But then maybe it's not worth the hassle. In retrospect, I'm pretty sure it's too late to change this. > But if we leave the behavior alone, at least it should be documented > correctly. Here's a proposed patch to document the current behavior > more accurately, which is a minimal fix for now. > > 2007-06-04 Paul Eggert <[EMAIL PROTECTED]> > > * doc/coreutils.texi (Common options): Mention that -h and > --human-readable are equivalent to --block-size=human-readable. > Documentation problem reported by Steve Ward in > <http://lists.gnu.org/archive/html/bug-coreutils/2007-06/msg00007.html>. > (du invocation): Use optSi rather than duplicating the macro's > contents (incorrectly, since we claimed a "B" was output). Thanks! Applied. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
