Hacker News new | ask | show | jobs
by db48x 8 days ago
> Or maybe you pipe into xargs and pray your filenames don’t have spaces…

Always use -0. Most gnu utilities support it. It makes them put a null byte after every filename instead of a newline. Completely eliminates the problem of dealing with whitespace in the filenames.

3 comments

To support your recommendation and redress the strawman the article postulates, the post's author could have replaced:

  find . -name '*.log' | xargs rm
With:

  find . -name '*.log' -print0 | xargs -0 rm
This one doesn't need xargs.

  find . -name '*.log' -delete
THANK YOU. I kept nodding along to all of the xargs comments, thinking “sure, but what about the even easier solution?”
As well as find has an -exec param to perform things one at a time or all with the same command by using a slash semicolon or a plus sign respectively:

  #order files from different levels in a file hierarchy by size:
  find . -type f -maxdepth 1 -exec ls -hlrS {} +

  #output metadata for each file sequentially
  find . -type f -maxdepth 1 -exec file {} \;
No dependency on GNU required anymore, POSIX 2024 supports it: https://blog.toast.cafe/posix2024-xcu#the-null-option
Neat, I didn’t know that! Even cooler that they’ve started to change all the core utilities to error out instead of creating a file with a newline character in it.
For tools that don't support -0, you can add the NULs yourself without much fuss. It's a one-liner in awk/perl/sed. Very handy.
If you do not have -0 options in your xargs/find, I wonder if you will have those extensions in your awk/sed. Perl is a different story.
I think the parent was referring to using awk/sed to do the equivalent of:

    find ... | tr '\n' '\0' | xargs -0 ...
I.e., a blind replacement without the tool having any particular semantic understanding of what it's translating.

That still requires your xargs to have -0 support, though, and I'd be surprised to have that without the corresponding option on find. But I've done this before when feeding xargs from something other than find.

It is also built on the assumption that filenames never contain newlines, which is wrong in general.

It's baffling to me that POSIX allows non-printable characters in file names, but here we are. Surely they had a reason for this decision.

That’s changing, maybe eventually even on real systems: https://blog.toast.cafe/posix2024-xcu#the-nuclear-option