Re: ls -Rd behavior

[Bob Proulx]

John Cowan wrote:
> Eric Blake scripsit:
> > The problem is that TRT isn't defined.  Suppose you have a/b/c, and pwd is
> > in a.  Should 'ls -dR *' print data on b/c, or stop recursing at b?

I think that it should invoke the game of rogue.  It could even still
claim compliance to the standards since that behavior is not
defined.  :-)

> On my assumption that -R controls what files ls visits, and -d controls
> what is printed about them, I'd say it should print data on b/c; i.e.
> recurse all the way down, printing information on all files and
> directories found, basically like "find | xargs ls -d".

Ugh.  I would not like that.  I think that -R either should override
-d or the combination should be an error.  I don't think having a
combination option such as that should create a third behavior.  What
is the behavior of 'ls -Rd' then?

> > Not that I'm opposed to a change in behavior.  But it is much quicker to
> > code up a patch that rejects the combination, since the current semantics
> > are confusing, than it is to do a more complicated patch and document how
> > the two interact.
> 
> I agree that it's better to complain than just to silently ignore one
> switch, and I am not opposed to such a patch: I do think it should say
> something like "ls -dR not yet implemented; try find | xargs ls -d".

Note that newer find commands can support the behavior more
efficiently in one process without needing to worry about argument
escaping.

  find . -exec ls -d {} +

> > Compare how coreutils behaves for other tough choices, such as
> > 'mv -t dest -T src'.
> 
> Not comparable:  -t and -T really are logically contradictory, and the
> error message is sensible.

I believe -d and -R to be logically contradictory too.

Bob