GNU bug report logs - #49716
no -print0 for ls?

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Vito Caputo <vcaputo <at> pengaru.com>
Cc: 49716 <at> debbugs.gnu.org
Subject: bug#49716: no -print0 for ls?
Date: Sat, 24 Jul 2021 18:05:10 +0100

On 24/07/2021 17:34, Vito Caputo wrote:
> 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...

Perhaps it might be useful when ls is just outputting names,
but would be then disallow a -z option with -l,
because -l has various ambiguities in output leading to non obvious programmatic handling issues.

Do your files have '\n' in them?  If not you might try:

  ls -Sr | tr '\n' '\0' | xargs -r0 mpv

thanks,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.