bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49716: no -print0 for ls?


From: Vito Caputo
Subject: bug#49716: no -print0 for ls?
Date: Sat, 24 Jul 2021 09:34:59 -0700

On Sat, Jul 24, 2021 at 02:22:14PM +0100, Pádraig Brady wrote:
> On 24/07/2021 08:03, Vito Caputo wrote:
> > Am I going senile here or does ls really not have a `find -print0`
> > equivalent?
> 
> This was previously discussed as noted at:
> https://www.gnu.org/software/coreutils/rejected_requests.html#ls
> 
> In summary, ls output is mainly for non programmatic consumption.
> Also find also provides this functionality as you say.
> 

This isn't really a satisfactory rationale IMNSHO, and the chain of
links you just sent me down is basically a bunch of echoing the same
incredibly weak rationale.

I recently tripped over this when just wanting to watch a directory of
video files in ascending file size order.  A simple `ls -Sr | xargs
mpv` would do the trick, but the filenames turned out to be a real
mess warranting -0.  Trivial to add -0 to the xargs, but not so for
the ls command, wasting significant time digging through its man page.

Are we really expecting a user in this situation to then go read the
find(1) man page and figure out how to prevent it from recursive
operation, produce null termination, *and* sort the results by file
size in ascending order?

When they already have the exact `ls -Sr` invocation in hand?

This seems asinine to me, the entire unix philosophy is composable
utilities and ad-hoc pipelines.  `ls` is arguably the most familiar
and reflxively used of those utilities.  I see no reason to prevent
the user from making its output robust against newlines in pipeline
scenarios like the one described above.  Especially considering a
patch has already been submitted to add it...

Thanks,
Vito Caputo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]