On 8/19/07, Bob Proulx <[EMAIL PROTECTED]> wrote:
> 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 {} +
Indeed, even quite old versions of GNU findutils can do something
broadly s
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 si
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to John Cowan on 8/17/2007 10:35 AM:
> Eric Blake scripsit:
>
>> Since POSIX states "The use of -d with -R produces unspecified results,"
>> should
>> we change ls to reject -Rd and -dR as invalid option combinations rather
>> than
>> th
Eric Blake scripsit:
> Since POSIX states "The use of -d with -R produces unspecified results,"
> should
> we change ls to reject -Rd and -dR as invalid option combinations rather than
> the current behavior of ignoring -R when -d is present?
Better yet, why not DTRT?
-R is about what objects
Since POSIX states "The use of -d with -R produces unspecified results," should
we change ls to reject -Rd and -dR as invalid option combinations rather than
the current behavior of ignoring -R when -d is present?
--
Eric Blake
___
Bug-coreutils m
