Building LFS/BLFS on USB.

Michael Shell list1 at
Sun Apr 8 02:17:25 PDT 2007

On Sun, 08 Apr 2007 20:03:12 +1200
Simon Geard <delgarde at> 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:

ls doc

and I probably would want

ls .

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:

ls d*

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 

ls d*

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 mailing list