3 ms·
Be aware that process substitution (and named pipes) can bite you in the arse in some situations --- for example, if the program expects to be able to seek in t
by david-given 12y ago
Be aware that process substitution (and named pipes) can bite you in the arse in some situations --- for example, if the program expects to be able to seek in the file. Pipes don't support this and the program will see it as an I/O error. This'd be fine if programs just errored out cleanly but they frequently don't check that seeking succeeds. unzip treats a named pipe as a corrupt zipfile, for example:
$ unzip <(cat z)
Archive: /dev/fd/63
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /dev/fd/63 or
/dev/fd/63.zip, and cannot find /dev/fd/63.ZIP, period.
- aidos 12y agoUseful. I'm assuming those are cases where normal pipes would fail too? So you can't do: cat z | unzip # I know, uuoc, demo only It's just with the process substitution you have more flexibility to shoot yourself in the foot?
- david-given 12y agostdin and stderr are assumed to always be streams, so anything which accepts them won't seek on them. However, if you give a program a filename on a command line, the program's likely to assume it's an actual file.
- Wicher 12y agoAside: If I recall correctly, with the zip file format, the index is at the end of the file. A (named) pipe works fine with, for instance, a bzipped tarball. I wouldn't be surprised if the ZIP file format has its origins outside the Unix world given its pipe-unfriendlyness.