Re: shred bug? [was: Unidentified subject!]
On Sun 11 Feb 2024 at 09:54:24 (-0500), 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...
>
> 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.
Perhaps info puts it better?
A FILE of ‘-’ denotes standard output. The intended use of this is
to shred a removed temporary file. For example:
i=$(mktemp)
exec 3<>"$i"
rm -- "$i"
echo "Hello, world" >&3
shred - >&3
exec 3>-
However, the command ‘shred - >file’ does not shred the contents of
FILE, since the shell truncates FILE before invoking ‘shred’. Use
the command ‘shred file’ or (if using a Bourne-compatible shell) the
command ‘shred - 1<>file’ instead.
Cheers,
David.
Reply to: