[Top][All Lists]
[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