> why are pipes even being allowed in the file name in the first place?

Why not? It's a perfectly legitimate (printable) character. The filesystem can't know that one shell or another will come along and use it (and several other characters) for special purposes.

I go the opposite way and rather question why slashes aren't allowed. Non-printable characters, though, I think we could do without them. Put differently, I think it makes sense to let filenames consist of characters, rather than of bytes.

>I go the opposite way and rather question why slashes aren't allowed.

You mean aside from the obvious reason that a slash is the path seperator?

I'm thinking that a path should be a list of directory names (and possibly a file name at the end), not tied to any particular way of representing this list. In some contexts, such as in a shell, concatenating the directory names, with slashes between them, ("/home/bromskloss/hello.txt") might be the way to represent it. In that case, a slash in the name would have to be escaped. Other times, such as in code, an array might be cleaner (["home", "bromskloss", "hello.txt"]).

There are filesystems that let filenames consist of any Unicode characters. Tag-based filesystems do not need to rely on special cased path separators, as long as they provide a sufficient UI and API for file management and interaction.

Linux allows any byte to be a part of a filename except for the null byte and '/'. It's not the kernel or filesystem's fault if some program like sh treats some characters like '|' specially.

But I don't get why you need to use the shell to get your file?

If you have a filename maybe you should manipulate the file directly instead of delegating to the shell.

Interestingly enough, Cocoa on OS X allows '/' but disallows ':', and maps them back and forth when going down to the Darwin layer, as ':' used to be the (always invisible in the UI) path separator pre-OS X.

I'm wondering now if you're as old as I am (old enough to have written code for OS9), or if you're younger but curious about archeological wierdnesses in modern OSs...

> not why popen is being used on the result of the interpretation.

I haven't read the source but I'm guessing that if HAVE_POPEN is undefined, this special argument interpretation is disabled, in which case it would just be two different ways of looking at the same thing.

> Also, why are pipes even being allowed in the file name in the first place?

The sibling comments are correct, but whether or not POSIX supports pipe characters in filenames is irrelevant for the issue at hand. ImageMagick is free to allow any kind of character in the arguments that it accepts. There is no POSIX/*nix magic that would ensure all arguments passed on the command line (or in the xlink:href attribute, as per the SVG example) are valid filenames.