Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the '-print0 and -0 are the only safe choice' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
-print0 and -0 are the only safe choice
Authored by: haa on Jul 21, '09 07:57:06AM

Filenames can also contain newlines (LF, \n) as well as other special characters, so replacing them isn't safe.

Unix filenames can contain any characters/bytes except NULs (this is why -print0 and -0 are safe). Space is not the only "weird" character out there.

When working with Unix find and xargs, using find ... -print0 and xargs -0 ... is the only safe choice. When working with shell scripts, carefully remember to put "" quotes around any variable names used as "$values".

Many people have started writing "shell" scripts with perl or other real programming language where you have more control of your data, to avoid working around the many "interesting" "features" of the Unix shell.

It is very easy to make files with \n in filenames, e.g. start bash and type
echo foo > 'barENTER
baz'ENTER

into it.

OSX ls shows the newline as ? for some safety by default. Use ls -lb to see the actual special characters in C-style or ls -lv for as-is display (try putting e.g. terminal escape sequences into file names for additional "fun").

[ Reply to This | # ]

-print0 and -0 are the only safe choice
Authored by: lar3ry on Jul 21, '09 09:14:58AM

On Unix, there are other "special" characters that cannot be present in file names. Forward slash (/) comes immediately to mind.

I think there are other special characters defined in POSIX that are not safe to have in file names, and the Mac may impose the restriction of colons as well.



[ Reply to This | # ]
-print0 and -0 are the only safe choice
Authored by: tim1724 on Jul 21, '09 03:23:29PM

On Unix, there are other "special" characters that cannot be present in file names. Forward slash (/) comes immediately to mind.

I think there are other special characters defined in POSIX that are not safe to have in file names, and the Mac may impose the restriction of colons as well.

Nope. POSIX only forbids slashes and nulls in filenames. Slashes because they're used for separating components of a pathname, and nulls because system calls that accept pathnames use null-terminated strings.

A particular filesystem may have other rules, particularly for non-ASCII characters, but POSIX doesn't say anything about that. It's true that HFS+ doesn't allow colons in filenames, but it does allow slashes. So if you put a colon in a filename, it will be turned into a slash when stored on an HFS+ disk. But when viewed via POSIX-compliant programs, such as "ls", you'll see it as a colon.

Try it yourself. Run touch : and then do an ls and see the result. You have a file called ":". Now look at it in the Finder. You'll see a file named "/".

Carbon file manipulation APIs use colon-delimited paths, and will see it as a file named "/". Cocoa file manipulation APIs (and traditional BSD APIs) use slash-delimited paths, and will see it as ":". On disk it's stored as "/" if it's a HFS+ disk, or ":" if it's a UFS disk.

It will always show up as ":" in command-line programs, but will nearly always show up as "/" in GUI programs. (The exception is in programs where POSIX paths are shown, such as the "Where" field in the Finder's info windows, or in many of the developer tools. Also, in any Cocoa program which shows raw pathnames, instead of using NSFileManager's -displayNameAtPath: method.)

---
Tim Buchheim

[ Reply to This | # ]