emacs-bug-tracker
[Top][All Lists]
Advanced

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

[debbugs-tracker] bug#19262: closed (rm command removes a read-only file


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#19262: closed (rm command removes a read-only file without confirming when the stdin is closed)
Date: Wed, 03 Dec 2014 17:28:02 +0000

Your message dated Wed, 03 Dec 2014 10:27:01 -0700
with message-id <address@hidden>
and subject line Re: bug#19262: rm command removes a read-only file without 
confirming when the stdin is closed
has caused the debbugs.gnu.org bug report #19262,
regarding rm command removes a read-only file without confirming when the stdin 
is closed
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
19262: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19262
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: rm command removes a read-only file without confirming when the stdin is closed Date: Wed, 03 Dec 2014 17:57:49 +0900 User-agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.0 Mule/6.0 (HANACHIRUSATO)
Hello,

$ touch a; chmod 0444 a; ls -l a
-r--r--r-- 1 foo bar 0 Dec  3 14:25 a

$ echo a | xargs /bin/rm -v
removed 'a'

Or,

$ touch a; chmod 0444 a; ls -l a
$ /bin/rm -v a 0<&-
removed 'a'

Is this a bug or a feature ?

Best regards.



--- End Message ---
--- Begin Message --- Subject: Re: bug#19262: rm command removes a read-only file without confirming when the stdin is closed Date: Wed, 03 Dec 2014 10:27:01 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
tag 19262 notabug
thanks

On 12/03/2014 01:57 AM, Takahashi Mamoru wrote:
> Hello,
> 
> $ touch a; chmod 0444 a; ls -l a
> -r--r--r-- 1 foo bar 0 Dec  3 14:25 a
> 
> $ echo a | xargs /bin/rm -v
> removed 'a'

Thanks for the report.  This is NOT an instance of stdin being closed.
POSIX says for xargs:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/xargs.html

"The results are unspecified if the utility named by utility attempts to
read from its standard input" - but this means that xargs has a choice
of either passing the _same_ stdin to the child (so rm's stdin is a
pipe) or a different stdin such as /dev/null (but rm's stdin would still
not be closed, but just be something that reads EOF without corrupting
xargs' stdin).  But either way, the behavior of 'rm' that you see here
is required by POSIX:

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

Step 2.b.:
"If the -f option is not specified, and either the permissions of file
do not permit writing and the standard input is a terminal or the -i
option is specified, rm shall write a prompt to standard error and read
a line from the standard input...."

Rationale:
"For absolute clarity, paragraphs (2b) and (3) in the DESCRIPTION of rm
describing the behavior when prompting for confirmation, should be
interpreted in the following manner:

    if ((NOT f_option) AND
        ((not_writable AND input_is_terminal) OR i_option))"

Given that you did NOT use either -f nor -i, then the determination of
whether to warn on whether the file is read-only is based on whether
stdin is a terminal.  /dev/null is not a terminal.  Ergo, no prompt.
And it's a good thing too - since you would have undefined behavior if
'rm' _did_ attempt to read from the stdin that it inherited from xargs.

> 
> Or,
> 
> $ touch a; chmod 0444 a; ls -l a
> $ /bin/rm -v a 0<&-
> removed 'a'

This is undefined behavior, per POSIX (starting ANY application with
stdin closed is undefined; in some cases, the OS may choose to start the
app with stdin pointing to /dev/null instead of being closed, but you
can't rely on that happening).  But the answer is the same whether stdin
remains closed by the OS or whether it was opened to /dev/null - either
way, stdin is not interactive.

> 
> Is this a bug or a feature ?

Feature, mandated by POSIX (arguably an odd requirement, but it matches
historical practice that people have come to rely on, so we can't change
it).  Therefore, I'm closing this as not a bug, although you should feel
free to reply if you have further comments or questions.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---

reply via email to

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