3 ms·

Filenames can contain newlines? You learn something new (and vaguley horrifying) every day.

rmaccloy 17y ago
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.
- mncaudill 17y ago
  I instinctively cringe whenever I see an odd looking 'rm' command.
- aw3c2 17y ago
  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.
mustpax 17y ago
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
- BrandonM 17y ago
  Why not just find . -name "*.o" -delete ?
  - michaelcampbell 17y ago
    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(/)
__david__ 17y ago
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".
- blasdel 17y ago
  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.
duskwuff 17y ago
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.

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.

mncaudill 17y ago
I instinctively cringe whenever I see an odd looking 'rm' command.
aw3c2 17y ago
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.

mustpax 17y ago

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

BrandonM 17y ago
Why not just find . -name "*.o" -delete ?
- michaelcampbell 17y ago
  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(/)

__david__ 17y ago

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".

blasdel 17y ago
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.

duskwuff 17y ago

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.