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
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
