On Sun, 08 Apr 2007 20:03:12 +1200 Simon Geard <[EMAIL PROTECTED]> 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: demo.txt doc: blah blah 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 level". 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. Cheers, Mike -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
