tag 367691 fixed-upstream
thanks
On Wed, Apr 18, 2007 at 03:44:11PM +0200, Jim Meyering wrote:
> Justin Pryzby <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Apr 18, 2007 at 05:11:38AM +0200, Jim Meyering wrote:
> >> Justin Pryzby <[EMAIL PROTECTED]> wrote:
> >> > This bug is not fixed. The code in coreutils-6.9 fails to treat -D as
> >> > an option independent of -P and -L. This has the effect that -D implies
> >> > -L, and du -DL is not the same as du -LD.
> >>
> >> Please provide an example demonstrating this.
> >> Or point to parts of the code and explain how that can be true.
> > So I think we agree on the intended behavior.
As it turns out, I think my understanding was wrong.
> > I'm afraid my example was wrong.
> >
> > If I call du -DP I get symlink_deref_bits=FTS_PHYSICAL, but if I call
> > du -PD I get symlink_dref_bits=FTS_COMFOLLOW|FTS_PHYSICAL.
>
> That is deliberate.
> Last one used (of -D, -P, -L) takes effect.
I see. The (generated) manpage documentation is unclear on this.
(For comparison, find.1 is clear). I'm tempted to suggest this --help
output:
-[DH], --dereference-args dereference only symbolic links listed under FILEs
-L, --dereference dereference all symbolic links
-P, --no-dereference don't follow any symbolic links (this is the
default)
> With -D, du dereferences all command-line-specified symlinks.
^^^
only is a key word here.
Thanks
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
