Re: shred bug? [was: Unidentified subject!]
On 2/11/24 06:54, Greg Wooledge wrote:
On Sun, Feb 11, 2024 at 03:45:21PM +0100, tomas@tuxteam.de wrote:
On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote:
On Sun, Feb 11, 2024 at 08:02:12AM +0100, tomas@tuxteam.de wrote:
[...]
What Thomas was trying to do is to get a cheap, fast random number
generator. Shred seems to have such.
Well... I certainly wouldn't call it a bug. Maybe a feature request.
Still there's the discrepancy between doc and behaviour.
There isn't. The documentation says:
SYNOPSIS
shred [OPTION]... FILE...
I interpret the above line to be a prototype for invoking the shred(1)
program:
* "shred" is the program name
* "[OPTION]..." is one or more option specifiers that may be omitted.
Each should be described below.
* "FILE..." is one or more argument specifies that should be file system
paths (strings).
DESCRIPTION
Overwrite the specified FILE(s) repeatedly, in order to make it harder
for even very expensive hardware probing to recover the data.
If FILE is -, shred standard output.
I interpret the above line at face value -- if the caller provides a
dash as the argument, shred(1) will operate on standard output.
In every sentence, the word FILE appears. There's nothing in there
which says "you can operate on a non-file".
Dash is not a file, yet the above sentence says shred(1) can operate on it.
Once you grasp what the command is *intended* to do (rewind and overwrite
a file repeatedly), it makes absolutely perfect sense that it should
only operate on rewindable file system objects.
An expert may infer what you have stated, but I prefer manual pages that
are explicit.
The GNU project must have found a need for the FILE='-' feature,
otherwise it would not exist. The manual page should describe that need
(e.g. why) and how to properly use shred(1) to solve the need.
If you want it to write a stream of data instead of performing its normal
operation (rewinding and rewriting), that's a new feature.
Humans are (in)famous for doing unexpected things.
If you'd prefer the documentation to say explicitly "only regular files
and block devices are allowed", that would be an upstream documentation
*clarification* request.
Apparently, shred(1) has both an info(1) page (?) and a man(1) page.
The obvious solution is to write one document that is complete and
correct, and use it everywhere -- e.g. DRY.
David
Reply to: