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
