bug#49716: no -print0 for ls?

[Vito Caputo]

On Sat, Jul 24, 2021 at 06:05:10PM +0100, Pádraig Brady wrote:
> 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.
> 

Yes, it only makes sense with plain names in single-column format.

But that usage style has significant applicability... Couldn't we make
-0 and any aliases shorthand for a new --format=WORD where WORD is
names0 or something.  That way it's automatically mutually exclusive
with the other formats?


> Do your files have '\n' in them?  If not you might try:
> 
>   ls -Sr | tr '\n' '\0' | xargs -r0 mpv
> 

There were newlines in some of the names...

It was just one of those situations where you know you have a heap of
crazy web-scraped titles, and you have no interest in making
assumptions about what is or isn't in there.  So you just want
nul-terminated strings and to not fret about anything going awry.

Thanks,
Vito Caputo