11 ms·

> The simple solution to the problem is to disable the popen support (HAVE_POPEN) Is it just me or is this the wrong way to tackle this? The question to me is

> The simple solution to the problem is to disable the popen support (HAVE_POPEN) Is it just me or is this the wrong way to tackle this? The question to me is why the file name being interpreted in some way in the first place, not why popen is being used on the result of the interpretation. Also, why are pipes even being allowed in the file name in the first place? (I'm asking about POSIX/*nix here, not about ImageMagick.)

AgentME 10y ago
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.
- rtpg 10y ago
  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.
- lloeki 10y ago
  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.
  - bigiain 10y ago
    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...
Bromskloss 10y ago
> 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.
- Sir_Cmpwn 10y ago
  >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?
  - Sephr 10y ago
    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.
  - Bromskloss 10y ago
    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"]).
julian37 10y ago
> 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.

AgentME 10y ago

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.

rtpg 10y ago
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.
lloeki 10y ago
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.
- bigiain 10y ago
  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...

Bromskloss 10y ago

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

Sir_Cmpwn 10y ago
>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?
- Sephr 10y ago
  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.
- Bromskloss 10y ago
  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"]).

julian37 10y ago

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