Hacker News Reader

Comment by DanHulton | Hacker News Reader

Filenames can contain newlines?

You learn something new (and vaguley horrifying) every day.

Traditionally Unix filenames can contain everything except for / and null (aka \0). This is why the find utility provides a facility for printing null terminated filenames (-print0), when used in conjunction with xargs -0 this is a fool proof way of iterating over files in the shell.

For example, to delete all .o files in the current directory and its subdirectories:

   find . -name "*.o" -print0 | xargs -0 rm -f

Why not just

  find . -name "*.o" -delete

?

That's fine for /this/ example because find provides that as an option. But you might want to grep for something in many files of varying depths, or run some home-brewed script on them for which find does not provide a built-in. -exec works of course, but spawns grep (or whatever) once per file; using xargs saves considerable time since it passes lots of files to 1 command.

Or, you can use zsh.

    rm **/*.o

    grep foo **/*.{java,sql,xml}

    # Where is that blasted IBM utility?
    ls **/*pmt*(x.)  # list e(x)ecutable files (.) that have "pmt" in their name.


    # Show me all the "Setup" dirs in my project
    ls -d **/Setup(/)

Filenames can contain plenty of happy stuff.

$> touch -- --

$> rm --

usage: rm [-f | -i] [-dPRrvW] file ... unlink file

$> rm -- --

$> touch \

$> touch \\ \ \ . \-

favorites of malware authors everywhere.

On a sidenote, creating a -i file in important directories can help against accidental "rm -rf"s. The -i will be given to rm as switch and rm will now prompt for each file. Of course backups are better but this might just safe your ass that certain time.

I instinctively cringe whenever I see an odd looking 'rm' command.

As noted above, I've seen some concepts thrown around about a (Linux) kernel patch to disallow filenames which contain unprintable characters, and I approve of them.

Yep. Though I don't think I've ever seen an actual legitimate use of this capability. I mean really, what's the point of an embedded newline...

Actually the Mac uses (or at least "used") a hidden files named "Icon\r" (yes, an embedded carriage return) for its custom folder icons. I'm still not sure that counts as "legitimate".

I had to write a one-liner to deal with that on Mac OS 10.4 -- had to detect if a user had placed anything on their Desktop, which had a custom folder icon because it was actually a cross-filesystem symlink:

  desktop=$(test -z $(ls -A1 /Volumes/Documents/Desktop | \ 
            sed -e '/^.DS_Store$/d' -e '/^Icon^M$/d'))

The ^M was a literal CR, which would get munged by all my usual editors except vim. I'm sure there's some sturdier way to escape it...

I remember choosing to use ls intentionally, but not what sucked about the alternatives.

Reply on news.ycombinator.com