bug#21218: ls -d

[Sneeh, Eddie]

Thanks again Assaf, please see below...

On Mon, Aug 10, 2015 at 8:05 PM, Assaf Gordon <address@hidden> wrote:

Hello Eddie,

> On Aug 10, 2015, at 19:24, Sneeh, Eddie <address@hidden> wrote:

> I guess what it boils down to is "-d" is a confusing choice of option for what it really does.  "ls --directory" has little to do with directories, (and adding the word "themselves" to the definition doesn't really remove much ambiguity), -d lists everything at one level, non-directories included!

I can see why this might be confusing.
If there are suggestions for improved wording (while still being concise and clear), then it might be possible to change the help/man pages.

 The problem is the behavior of ls -d is so erratic it's difficult to describe in a concise way.  I haven't seen the code or the spec, so my suggestion is based solely on observation (which may or may not be complete).  Here's one shot at it, see if you agree or disagree with it:

-d:   --directory, --donotdescend:   Useful only when "*" is part of the argument(s).  The same as ls but does not descend into subdirectories.

​

​Adding ​

--donotdescend

​provides

a little bit of

​"credibility" and ​

a true meaning to -d because certainly --directory doesn't make much sense.

​  I assure you, every user I've worked with over the years that had a question about this was as confused as me.​

However, regarding the functionality of '-d' - that I'm quite certain will not change.
It is a long-established behavior of 'ls', one that has been standard on many operating systems and for many years (possibly decades? I'm too new to know for sure).

​Yeah, this is not something that I've just discovered suddenly; I don't know why I decided to "complain" today.  

​

​An unusually slow Monday perhaps.  ​

I'm fully aware that changing the behavior of ls -d , -f , -l etc.. is not practical, not the right thing to do, but what can be done

​, for the sake of improvement, ​

​is to provide

a clearer definition that reflects the true behavior

​, something along the lines of what I suggested above.

​

 

But perhaps look at it from another perspective:

you've mentioned two requests of affecting ls's output:

> what I suggested is more intuitive:
> ls -d (list directories)
> ls -f (list files)
> ls -l (list links)
and:
> The current -d should have been something like: --1level or --dont_descend or the like.

When in fact, 'find' has exactly these options!

​My point is, when a user wants to list directory contents, they think ls first.

"find" is a very useful utility, I like it a lot, and I use it a lot.  There are no issues with "find", and this is not about how to use "find", it's about "ls -d".  Appreciate the intent and the helpful examples though.

​

If you think of 'ls' as:
  list files, catering to the most common use-cases,
and think of 'find' as:
  list files with maximum flexibility of filters and conditions
then the distinction between them becomes clearer.

With find you can already performs your requested options:
  find -type f (list regular files)
  find -type l (list symbolic links)
  find -type d (list directories)
  find -maxdepth 1 (don't descend into sub-directories)

and 'find' allows you even more, because you can combine these conditions in as flexible way as you'd like.
for example, to list all directories up to 3 levels down, which start with 'b', owned by me and are writable:
  find . -maxdepth 3 -name "b*" -user assaf -writable
or, list all regular files in the current directory that have been accessed in the last 24 hours, and print their name and size:
   find . -maxdepth 1 -type f -atime 1 -printf "%s %f\n"

My point is, the moment you need more than basic listing of files,
you should switch from 'ls' to 'find'.
This way we can avoid adding more functionality to 'ls' because it already exists in 'find'.

regards,
 - assaf

--

Best Regards,

Eddie Sneeh