[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Lzip-bug] non-S_ISREG files
From: |
John Reiser |
Subject: |
[Lzip-bug] non-S_ISREG files |
Date: |
Mon, 15 Dec 2008 09:55:46 -0800 |
User-agent: |
Thunderbird 2.0.0.18 (X11/20081119) |
Hi,
Currently open_instream()/main.cc rejects any non-S_ISREG file.
This causes trouble with
S_ISFIFO named pipe
S_ISSOCK socket
S_ISLNK symbolic link
/dev/stdin Linux-specific symlink to /proc/self/fd/0
/proc/<pid>/fd/n Linux-specific symlink
S_ISBLK block special device
S_ISCHR character special device
I would like to see an enhancement so that S_ISFIFO, S_ISSOCK, and
S_ISLNK are treated as if they were piped to stdin, and either create
a new output file or use stdout. Give a warning on stderr if not in
--quiet mode. Treat the input as a read-only unnamed data stream.
Do not manipulate the file by replacing its contents with the compressed
version and appending ".lz", etc.
"But the user could just pipe the fifo/socket/symlink as stdin
in the first place." This is true when running lzip directly, such as
from the top-level of an interactive shell. However, when using lzip
from within a script or another utility program, then it is a useful
convenience, simplification, and reduction in complexity to avoid
special cases. Also, there are useful situations where a "cabal
of processes" is involved: something other than a sequential linear
pipeline of processes. The most common example is running /bin/cmp
with two generated input streams (pipes). Something approximately like:
... | /bin/cmp - /proc/self/fd/6
where the establishment of fd6 can be difficult to express in shell.
Treating S_ISBLK and S_ISCHR as if they were pipes is analogous
but the usage is much less frequent. (The case where S_ISBLK is a
whole filesystem comes to mind.) I feel less strongly
about these two cases than I do about fifo/socket/symlink.
Regards,
--
John Reiser