bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#367691: coreutils: behaviour of du -x[LDP] differs from that of


From: Justin Pryzby
Subject: Re: Bug#367691: coreutils: behaviour of du -x[LDP] differs from that of du -[LDP]x
Date: Fri, 19 May 2006 11:29:20 -0400
User-agent: Mutt/1.5.11+cvs20060403

On Fri, May 19, 2006 at 04:54:47PM +0200, Jim Meyering wrote:
> Justin Pryzby <address@hidden> wrote:
> ...
> > I don't think this is right.
> 
> If you can come up with an example where it fails,
> I'd appreciate it -- and would add a test case.
I think this is mostly just a manpages bug, or perhaps a bug in my
understanding..

> > Quoting the manpage:
> > |    There are a number of options, at least one of which (either 
> > FTS_LOGICAL
> > |    or FTS_PHYSICAL) must be specified.  The options are selected by or'ing
> > |    the following values:
> >
> > so this will supposedly cause du to fail if -D is given.  I just wrote
> > a small test for this, and it appears to be false that (exactly?) one
> > of FTS_{LOGICAL,PHYSICAL} must be set.  The fts_{open,children,close}
> > all succeed.  I'm going to bug manpages about this (and some other
> > things).
> 
> Bear in mind that the man page documents glibc's fts.
> The coreutils one has been able to evolve, and as such
> has some incompatible ABI changes, and recently, some
> upward-compatible API changes.
Oh

> > In any case, it is my understanding that FTS_COMFOLLOW is really an
> > independent option, and so should be handled as an bit_flag.
> 
> Good point.
> Here's the additional change I'll probably make, along
> with the name change s/symlink_deref_bit/symlink_deref_bits/.
> 
> Index: src/du.c
> ===================================================================
> RCS file: /fetish/cu/src/du.c,v
> retrieving revision 1.225
> diff -u -p -r1.225 du.c
> --- src/du.c  19 May 2006 12:36:18 -0000      1.225
> +++ src/du.c  19 May 2006 14:47:48 -0000
> @@ -807,7 +807,7 @@ main (int argc, char **argv)
>         break;
>  
>       case 'D': /* This will eventually be 'H' (-H), too.  */
> -       symlink_deref_bit = FTS_COMFOLLOW;
> +       symlink_deref_bit = FTS_COMFOLLOW | FTS_PHYSICAL;
But -D shouldn't imply FTS_PHYSICAL, right?

|       This option causes any symbolic link specified as a root
|       path to be followed immediately whether or not FTS_LOGICAL
|       is also specified.

Just because I want commandline arguments (or function parameters) to
be followed doesn't mean that I don't want other links followed.

du -DL is redundant, but surely du -LD should do the same thing.

Justin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]