Your message dated Thu, 7 Jun 2007 16:15:15 -0600
with message-id <[EMAIL PROTECTED]>
and subject line Bug#427967: coreutils: rm -r ~dirname erases ../dirname, also
current working directory.
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: coreutils
Version: 5.97-5.3
Severity: normal
(running as root)
in /home/ there is a
/home/luf
directory.
in this directory there is a
/home/luf/~luf
directory.
having as current directory /home/luca
giving the command
rm -r ~luf
has removed entire /home/luf directory .
i tried again and found that even mkdir has a similar behaviour:
mkdir ~dirname does not create "./~dirname" but instead "../dirname"
this only ON this computer, on other 3 with the same release behaviour is
correct.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages coreutils depends on:
ii libacl1 2.2.41-1 Access control list shared library
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libselinux1 1.32-3 SELinux shared libraries
coreutils recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Leonardo Boselli wrote:
> in this directory there is a
> /home/luf/~luf
> directory.
Ugh. I can see where this is going. I am sorry for your loss.
> having as current directory /home/luca
> giving the command
> rm -r ~luf
> has removed entire /home/luf directory .
Yes. That is exactly what it would do. And in this case it would not
matter if you were not root because you would have permission in your
own home directory to remove the contents.
> i tried again and found that even mkdir has a similar behaviour:
> mkdir ~dirname does not create "./~dirname" but instead "../dirname"
This is true for all commands because this is not a command issue it
is a shell expansion issue. The command is expanded before these
commands even start running to be the full path to the directory.
Use the 'echo' command to output the command that would be run.
echo mkdir ~luf
What you will see is that the shell expands ~USER if a word begins
with a tilde. The word is treated as a login name and the word is
expanded to be the path to the home directory. The command is passed
as an argument the full path by the shell. The command itself does
not see the original characters typed by you at the command line. The
command only sees them after processing by the shell.
man bash
... Tilde Expansion ...
Assuming that you are using bash please see the bash manual section
"Tilde Expansion" for complete documentation on this behavior. Other
shells such as ksh, zsh, etc. often have this feature too.
The way to avoid the shell expanding these words they need to be
either quoted (e.g. "~something", '~something', \~something) or they
need to be prefixed. I recommend prefixing them.
echo mkdir ./~something
The same applies to all commands such as your case of 'rm' and not
just to the mkdir that I am using for my example above.
> this only ON this computer, on other 3 with the same release behaviour is
> correct.
I would assume that on the other systems that the user does not exist
there. The behavior is that if no expansion is possible then the word
is passed through unchanged. This is also true for other expansions
such as '*'. If no files exist in the directory to the '*' is passed
through unchanged. If any files exist then it is expanded. The same
is true for the ~user expansion. If no user exists to match then the
word is passed through unchanged.
This behavior appears to you differently on the different systems
because the shell behavior is dependent upon which users exist on the
system. If ~user exists then it is expanded. If not then it is not.
Because this is defined behavior is both not related to any of the
coreutils (it would affect all commands on the system) and it is
defined behavior for the command shell I am going to close this bug
against coreutils. I know that after having removed the whole
directory that this will not be a comfort to you. However if you talk
to enough people you will find that you are not alone in having done
something similar over the years. We have all done something like
this in the past.
Bob
--- End Message ---
