On 07/10/2026 15:16, Anonymousemail via GNU coreutils General Discussion wrote:
Powered by Anonymousemail
Hi everyone,
I'm writing about something that might sound trivial, but I think it deserves a
moment of reflection.
I'm talking about ls. Yes, the command all of us run hundreds of times a day.
My frustration comes from the fact that ls, in its standard form, has no simple
option to filter files by execute permission. To get a list of just the
executable files, the user is forced to reach for find — a powerful tool, sure,
but much more verbose and, in some contexts, far less immediate.
So here's my question: is it really acceptable that in 2026, for such an
elementary need, we still have to go through find, or worse, through fragile
and non-portable parsing of ls -l output? Wouldn't it make more sense to add an
option like --executable (or something similar) to ls, to filter results by the
x bit?
I'm well aware that ls is a POSIX command, that its syntax has been standardized for
decades, and that the Unix philosophy is "one tool, one job". But I have to
ask: isn't that philosophy, in this specific case, becoming an excuse for not adding a
feature that would improve the ergonomics of one of the most-used tools in existence?
One more thing, just to add insult to injury: find itself isn't even consistent
across platforms. On macOS (BSD), -executable doesn't exist and the permission
syntax differs from Linux (GNU). So anyone working on both systems has to
remember two different syntaxes to do the same thing. An option in ls would
solve that portability problem too.
I know this email will probably go nowhere, or that I'll get told "just use find and
stop whining". But I wanted to put my two cents in. If anyone feels like discussing
it, I'm here.
This was discussed previously:
https://www.gnu.org/software/coreutils/rejected_requests.html#ls
The summary from there was something like this was sufficient:
lx() { ls --color -lF | sed -n 's#\*$##p'; }
cheers,
Padraig
