Building LFS/BLFS on USB.
list1 at michaelshell.org
Sun Apr 8 02:17:25 PDT 2007
On Sun, 08 Apr 2007 20:03:12 +1200
Simon Geard <delgarde at ihug.co.nz> wrote:
> Really? It's always seemed perfectly sensible to me - if I run ls with a
> directory parameter, it ought to provide a listing of that directory.
> Other people's usage patterns may vary, but in 90% of cases, listing the
> given directory is exactly what I want.
Well, I might tend to agree for a single directory. For example:
and I probably would want
to list the contents of the current directory.
The problem comes in when wildcards are used. For example, suppose
I want to list all files/directories that begin with "d", but I've
also got a doc directory. Doing:
will then show the contents of doc which I don't want. This
problem may be an example of what I mean by the issue of shell
versus application regex evaluation. The shell will expand the
d* to, say:
ls demo.txt doc dump.bin
when ls sees that doc is a dir, it will list its contents.
One the other hand, if ls was the one to do the regex expansion,
I would expect
to mean, "show me a list of all the things in the current
directory that being with d". There is some awkwardness, IMHO,
in the ls output - blank line and directory name - when
directories have to be listed with files:
The other aspect is that cp needs a -R to descend into a
directory and I would think that ls would require an "-R" option
to descend into a directory. Of course, keeping things analogous
to cp would require ls to keep descending through all the
subdirectories, listing the entire tree - which is what the
actual -R ls option does. I guess, I'd want the "-d" option to
mean the opposite of what it does now, e.g., "descend only one
Sigh. I guess you are right - it depends on what operations
are most frequently wanted.
It's interesting to see the different points of view.
More information about the blfs-support