-4

I was directed to this StackExchange post:

Why is looping over find's output bad practice?

The core issue is that Unix filenames can contain any character except the null byte (\0). This means there is no printable character you can reliably use as a delimiter when processing filenames - newlines, spaces, and tabs can all appear in valid filenames.

A common solution is to use a null byte as the delimiter, which is supported by GNU find with the -print0 option. This allows you to safely process filenames using tools like xargs -0 or while read -d ''.

However, not all versions of find (especially non-GNU variants) support -print0. This raises the question: What should you do for portability when -print0 isn't available?

Frankly, it seems that find implementations lacking -print0 are fundamentally flawed for robust scripting and should not be relied upon in scripts that need to handle arbitrary filenames safely.

There was the suggestion to use find in combination with sh

find dirname ... -exec sh -c 'for f do somecommandwith "$f"; done' find-sh {} +

How does this fix the problem? One is still using a defective find. The link did not provide a clear explanation of why the combination of find with sh should work. How does it solve the problem?

Improve this question
16
  • Have you got a specific use case in mind? It would help to understand the specific problem you're trying to solve Commented Jun 9 at 17:18
  • This is a question regarding the discussion in the link. If the argumentation is that one should not rely on the GNU -print0 as stated, what is the procedure on other systems? Commented Jun 9 at 17:24
  • 1
    The suggestions to "use find in combination with sh" offered in at least two answers provide a general solution, which is why I'm asking if you have a specific use case Commented Jun 9 at 17:38
  • 2
    For the record, -print0 is now standard as of the 2024 edition of the POSIX standard. There are not that many find implementations left that don't support it. Even Solaris' does. In any case, you can always replace it with -exec printf '%s\0' {} +. What is less commonly available is portable ways to process that output. In any case, you don't need xargs, as find can execute commands directly. Commented Jun 9 at 18:11
  • 1
    @Filangieri "not reliable" suggests that it can fail. The issue is that it isn't portable, that it isn't available for every find implementation, not that it is not reliable. It is perfectly reliable when it is available. Commented Jun 10 at 12:00

1 Answer 1

Reset to default
3

-print is unreliable for further processing because that further processing requires parsing the output back into discrete file names. As you point out, that can’t be done reliably.

Using -exec instead (that’s the important part, not using sh) is reliable because it doesn’t involve parsing. find constructs the list of arguments given to the new command, and each file name is provided as a single argument, with no ambiguity as to separators. When executing a command, the command-line isn’t provided as a single string; it is provided as a data structure, with each argument in a separate entry. See man 2 execve for details.

In -exec sh -c 'for f do somecommandwith "$f"; done' find-sh {} +, sh is given the following arguments:

  • sh
  • -c
  • for f do somecommandwith "$f"; done
  • find-sh

followed by each file name, separately. The for loop then processes each file in turn with no parsing ambiguity.

Improve this answer
8
  • Without --exec you always get some delimiter between filenames? And with --exec the file name is passed as a single entity, one at a time? Commented Jun 9 at 18:08
  • @Filangieri, without -exec, you get -print which is the default action. The result is one stream of byte out of which you can't get the list of files back. With -exec cmd {} + the paths of the found files are passed as separate arguments to cmd by find. Commented Jun 9 at 18:14
  • Means that the way the filenames are passed is different, not just a stream, but a structure representing the filename, which is then processed by an sh process. Commented Jun 9 at 18:21
  • So why is it stated that -print0 is a solution? Commented Jun 9 at 18:31
  • 1
    I didn’t say anything about -print0 in my answer, let alone mention a dependency. You asked why -exec sh helps, is that no longer what you’re interested in? Commented Jun 9 at 22:02

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.