mjhjmtu

I'm confused by this experiment (in Bash):

$ mkdir 'foon'
$ find . -print0 | od -c
0000000 . . / f o o n 
0000012

As you can see, "find" is correctly delimiting the output with null characters, but it escapes the newline in the directory name as "foon" with a backslash "n". Why is it doing this? I told it "-print0" which says "This allows file names that contain newlines ... to be correctly interpreted by programs that process the find output." The escaping should not be necessary, since "" is the delimiter, not "n".

The problem is not in find, but in how you're creating this directory. The single quoted string 'foon' is actually a 5-character string, of which the last two are a backslash and a lowercase "n".

Double-quoting it doesn't help either, since double-quoted strings in shell use backslash as an escape character, but don't really interpret any of the C-style backslash sequences.

In a shell such as bash or zsh, etc. (but not dash from Debian/Ubuntu), you can use $'...', which interprets those sequences:

$ mkdir $'foon'

(See bash's documentation for this feature, called "ANSI C Quoting").

Another option, that should work in any shell compatible with bourne shell is to insert an actual newline:

$ mkdir 'foo
'

That's an actual Return at the end of the first line, only closing the single quote on the second line.

Let's make a directory named foo plus a newline:

$ mkdir $'foon'

Now, let's use find:

$ find . -print0 | od -c
0000000 . . / f o o n 
0000011

n is not escaped.

The issue is that mkdir 'foon' is the name is interpreted as foo followed by followed by n. We can verify that with:

$ printf '%s' 'foon' | od -c
0000000 f o o n
0000005