--- Begin Message ---
|
Subject: |
i miss some ls-features |
|
Date: |
Mon, 5 Mar 2018 22:01:41 +0100 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 |
hello
I wonder why for the ls-command I don't find the following features, I
consider important:
- list the size of files. For directories, list the total size of the
tree beneath them
- for ls -R (recursive presentation) limit it to a certain depth
greetings,
kalle
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#30717: i miss some ls-features |
|
Date: |
Mon, 5 Mar 2018 15:16:27 -0600 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
tag 30717 notabug
thanks
On 03/05/2018 03:01 PM, kalle wrote:
hello
I wonder why for the ls-command I don't find the following features, I
consider important:
- list the size of files. For directories, list the total size of the
tree beneath them
Because this feature is already provided by the 'du' tool.
- for ls -R (recursive presentation) limit it to a certain depth
greetings,
Because this feature is already provided by the 'find' tool.
One philosophy of Unix design is that each tool should do one thing
well, rather than trying to repeat functionality already present elsewhere.
As such, I'm marking this as not a bug in the coreutils database, but
you are welcome to continue conversation if you think you have strong
arguments for changing ls. Note that if there is an alternative
implementation of ls (such as BSD ls) that does what you want via a
particular command line option, then that is a much stronger argument
for teaching coreutils ls to do the same thing. But merely adding
something to ls that can already be accomplished by another standardized
tool is probably just going to be bloat to an already large 'ls' binary.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
--- End Message ---