[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ls -Rd behavior
From: |
John Cowan |
Subject: |
Re: ls -Rd behavior |
Date: |
Sat, 18 Aug 2007 22:08:32 -0400 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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?
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".
> 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".
> 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.
--
John Cowan http://ccil.org/~cowan address@hidden
Mr. Henry James writes fiction as if it were a painful duty. --Oscar Wilde