bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45700: rm should not prompt if ! isatty(2)


From: John Wiersba
Subject: bug#45700: rm should not prompt if ! isatty(2)
Date: Wed, 6 Jan 2021 20:31:47 +0000 (UTC)

 Thanks for your reply, Paul!
I see what you're talking about; thanks for the link.  The POSIX spec seems 
broken in that regard.  I guess I'm going to be adding -f to my scripts!  (I 
was surprised to see my script hang today for this very reason).  

Maybe something could be added to the FAQ or the manpage?  I didn't see 
anything documented about prompting for an unwritable file.  Although I'd seen 
those prompts before, I was surprised to find that prompting happens even when 
stdout is not a tty.  Something like this maybe:


Per the POSIX spec, rm will prompt to stderr before removing an unwritable 
file, even if stderr is not a tty.

Another possibility is to add a timeout on the prompt when writing a prompt to 
a non-tty (with an inferred reply of "no").
-- John

    On Wednesday, January 6, 2021, 2:17:00 PM EST, Paul Eggert 
<eggert@cs.ucla.edu> wrote:  
 
 On 1/6/21 10:56 AM, John Wiersba via GNU coreutils Bug Reports wrote:
> $ touch asdf && chmod a-w asdf && rm asdf 2>&1 | catrm: remove 
> write-protected regular empty file 'asdf'?          # should*not*  prompt
> 
> If the prompt cannot be seen, then it can't be properly answered, so there is 
> no point in prompting and consequently leaving the user with a hanging 
> command and no way to know what's being expected of them.  Instead rm should 
> attempt to remove the file and succeed or fail based on the result.

POSIX requires the current behavior; see clause 3 in:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html

Although GNU rm needn't follow POSIX blindly, it's doubtful that rm 
should remove the file in this particular case, as the longstanding 
tradition is that plain "rm" does not remove unwriteable files without 
more confirmation.

Since you know about "rm -f" I suggest using that (that's what everyone 
else does...).  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]