Re: shred bug? [was: Unidentified subject!]
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...
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.
In every sentence, the word FILE appears. There's nothing in there
which says "you can operate on a non-file".
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.
If you want it to write a stream of data instead of performing its normal
operation (rewinding and rewriting), that's a new feature.
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.
Reply to: