Hacker News Reader

Of course one any of those filenames contains a space, your first two examples break down, and in the worst case result in the wrong files being deleted. Of course one can work around that, but in reality, this quickly gets difficult, and often is forgotten. The print0 works for some cases, but not in general (e.g. when one needs to do more complex processing)

The second example is fine, to be fair. {} is replaced by a single argument, no shell magic here.

The second one doesn't fail, and the first one only fails because I wrote `rm $file` instead of `rm "$file"`, which I have done every single other time I've written the same thing this century.

Writing in first one won't save you since "in" splits by whitespace, not newline. If you really have to do that, use "find ... | while read file; do" instead.

Better:

    find ... -delete

Your first example breaks for filenames containing whitespace.

Filenames containing whitespace are, and always have been, a bloody stupid idea.

No, assuming filenames dont have whitespace is an idea that has fucked over people for a long time.

Sure, it's annoying in a shell when whitespace is used as a separator but that seems more of an issue with shells than with filenames.

Filenames should describe the file. In language, descriptions quite often require whitespace.

Whitespace should have been banned from filenames decades ago. If you need 'whitespace', use a hyphen or an underscore.

I agree, if you ever want whitespace to have any special meaning in your shell (and you do), allowing spaces within filenames just causes no end of headaches.

For interactive use, tab completion already takes care of the escaping. For anything else the actual headache is that things are passed around as strings and command argument parsing is done for the expanded string where spaces can cause different argument parsing unexpectedly. This is certainly not limited to filenames but any argument that can contain spaces and is passed to a different command without proper quoting. The very fact that it's so easy to get wrong is perhaps a sign that things are a bit broken. But not necessarily at the filesystem level ...

No, file names should describe the file. hyphens and underscores are hacks.

Systems should be better at handling files with unicode characters and spaces. Its the fault of the shell that whitespace has been overloaded, not filenames.

But whitespace was banned from file names decades ago, and look what happened: people wanted it added in. So it was added in. That's progress!

If the shell can't handle this well, the problem is that the shell is not very well designed, and we need something better.

Meanwhile, I never have problems with spaces in file names when I'm doing stuff in C++, C#, Python, etc.

Well they should be banned then, but they are not. Also it might be a stupid idea for regular use but not so stupid idea as an attack vector. Along with filenames starting with a dash.

But we must live with they.

> That list of files can come from anywhere. Does it come from a text file? A script? Or find? Doesn't matter.

This is an important concept. A powershell script might need to change depending on the source, sometimes it'll be a file object and other times a string, in unix it will always be a string. This is important for composability.

In practice, I seem to end up with a `sed` or `perl` script to mangle one string format into another between processes anyway. And then it all breaks between systems because half the most common commands have different defaults between systems.

You can't even encode lists of strings in a format that's reliably understood by all UNIX programs.

Nice. Also:

>If you do get them from find, you run things on them in precisely the same way you run things on any other list of files: a for loop. for file in $(find ...); do rm $file done

If you know the number of files (and hence total command line length) will not be too high (i.e. not exceed the maximum length of a Unix command-line [1]), and that the filenames will not contain spaces or other problem-causing characters, you can shorten that to:

    rm $(find ...)  # or rm -i $(find ...) for interactive deletion.

This will only run rm once, instead of once for each file.

If either or both of the above conditions are not met, your 2nd or 3rd snippets are preferable.

[1] IIRC, there is a constant defined for that maximum, somewhere in standard C library's header files (maybe something like BUFMAX). I've read that early versions of Unix commands used to crash in some way (core dump or seg fault) if the length was exceeded, and seen that a few times myself. Also may have read that it was quite short initially, like 512 or 1024 bytes. People might have done something to fix that, apart from xargs, later.

Update: I googled for this phrase:

maximum length of unix command line

and looked at the first few hits; found some info:

xargs --show-limits

can give info about the maximum length, which POSIX calls ARGMAX, not BUFMAX as I said above.

and a sample output of xargs --show-limits is:

Your environment variables take up 2446 bytes

POSIX upper limit on argument length (this system): 2092658

POSIX smallest allowable upper limit on argument length (all systems): 4096

Maximum length of command we could actually use: 2090212

Size of command buffer we are actually using: 131072

There is no limit per argument, but a total for the whole command line length. In my system (Fedora 15/zsh) its closer to 2Mb. (line 4).

(from http://stackoverflow.com/questions/6846263/maximum-length-of... )

One of the hits also says that

getconf ARGMAX

shows the value, on POSIX-conformant systems.