Re: shred bug? [was: Unidentified subject!]
On Tue 13 Feb 2024 at 07:15:48 (-0500), Greg Wooledge wrote:
> On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote:
> > … but not much. For me, "standard output" is /dev/fd/1, yet it seems
> > unlikely that anyone is going to use >&1 in the manner of the example.
>
> Standard output means "whatever file descriptor 1 points to". That
> could be a file, a pipe, a terminal (character device), etc.
Why pick on 1?
> > I might write something like: "The option ‘-’ shreds the file specified
> > by the redirection ‘>&N’", though there could be a better name for ‘>&N’.
>
> You're assuming the program will be used from a shell. This is *usually*
> going to be true, but nothing prevents you from writing a C program
> which closes stdout, opens a file, ensures that it's using FD 1,
> and then calls "shred -". The documentation has to support this use
> case as well.
/As well/ — which is why I wrote N in place of 1. The original bug
report (which I hadn't seen until Thomas' post) says:
"If you redirect output to a file it will work. Shredding a tty doesn't
make much sense, after all."
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175#10
Now, you can't write "If you redirect output to a file it will work"
in a man page—it needs recasting into something more like what
I wrote above, which contains two key points:
. It points out that '-' is an option, not a filename or a stand-in
for one, and it doesn't use the word standard, which is totally
irrelevant in the circumstances.
. It demonstrates the shell syntax element required (&) in order to
avoid truncating the file, rather than shred overwriting it.
I think that getting the "&" into the man page would be helpful
to anybody who doesn't look at the info page for the example.
It might have shortened the early part of this thread as well.
As for C programmers, neither FD number nor truncation is relevant.
Sure, you can pick 1. But you don't have to document that for shred.
And truncation is an accident that can occur because of shell's
redirect syntax: there's no equivalent in programs.
> > > 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>-
> >
> > I can see that the last line truncates the "anonymous" file,
>
> No, that's not what it does at all. In fact, that last line is
> written incorrectly. It should say "exec 3>&-" and what that does
> is close file descriptor 3, which was previously opened on line 2.
>
> What it actually does *as written* is create/truncate a file whose
> name is "-", close the previously opened FD 3, and make FD 3 point
> to the file named "-".
>
> unicorn:~$ exec 3>-
> unicorn:~$ ls -ld -- -
> -rw-r--r-- 1 greg greg 0 Feb 13 07:12 -
> unicorn:~$ ls -l /dev/fd/3
> l-wx------ 1 greg greg 64 Feb 13 07:12 /dev/fd/3 -> /home/greg/-
>
> This is an obvious bug in the info page. I wonder how many years
> this has gone unnoticed.
Well spotted. That's what an experienced eye brings to a line like
that, whereas I assumed it meant something beyond my experience,
and searched for it.
Ironic that it truncates a file, and then immediately warns against
truncating a file instead of shredding it.
Cheers,
David.
Reply to: