Re: Problem with 'rm -i' in ksh

In article <vm0ela$15i9h$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
...

It's called in a (ksh-)function within a structure like this
>
 function f { ... rm ... }
 p1 | p2 | while read ... do ... f ... done
 f

Well, that explains everything.

And you're going to get a dozen responses just like this one, pointing
out the obvious.

When you are in a "... | while read" loop, the stuff inside the while loop
has stdin coming from the pipe.  Yes, I've been bitten by this a few times,
and it is one of the (many) reasons I avoid the "... | while read" idiom.
There are always better/cleaner alternatives.

BTW, I was going to suggest that the best way to debug this was, assuming
you're running Linux, to add code just before the "rm" to do a "ls -lsa
/proc/self/fd/0" and you'll then know what fd 0 is.  My guess is that that
would show that fd 0 is something like: /proc/self/fd/0 -> pipe:[123456789]

A couple of comments:

    1) Keith made some good points about the possibility of changing how
"rm" behaves when stdin is not a tty.  Looks like we'll have to get
POSIX changed before we can change the program, although the idea
of adding a new flag (maybe -I instead of (i.e., in addition to) -i)
has merit.

    2) I've always thought that adding -i to rm as a safety feature was a
bad idea.  This is a total aside, but it seems common for system
admins to setup a global alias that aliases "rm" to "rm -i".  It
seems to me that if you want to make "rm" safer, you should alias
it to "rm -v" instead.  "rm -i" makes it hard to do large deletes
(like removing a whole directory) - since you get prompted over and
over and over.  With "rm -v", the users will know what they've done
and will learn quick to be careful.  I.e., the real danger with
"rm" without "-v" is that you can delete stuff without knowing it,
and only find out (much) later.

--
Religion is what keeps the poor from murdering the rich.

- Napoleon Bonaparte -