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
