rm question. ..

[someone_4]

Someone that I work with did this command
rm ./*
Thinking it would delete all the scripts in a dir. But it deleted everything in the dir. Now they come over half scared to death. They thought it deleted everything in the root dir. It about scared me to death too. But how I see it they only deleted everything in that pwd dir and no where else. The way I see it the . means the current dir. the / would be the path to the dir and the * deleted everything in the dir. So in terms just another way of doing
rm * Am I right?

Thanks
Richard

[A. Clay Stephenson · Accepted solution]

Hi Richard,

Yes, you are right. But 'only' doing rm * or rm ./* could still be a killer command depending on the current working directory.

Clay

[someone_4]

It was a home/usr/test dir.

So it didnt delete any important files.

Thanks My CLay

Richard

[someone_4]

Oppps i mean Mr. Clay

Richard

[James R. Ferguson]

Hi Richard:

I'd provide some protection. Create an alias for 'rm in the $HOME/.profile:

# alias rm='rm -i'

This way (at least) you are prompted to reply "y" or "n" before the file will be removed. Don't worry (or maybe, do): when executed in a script, the alias doesn't apply.

Regards!

...JRF...

[Thierry Poels_1]

hi,
I take it even further than James' <> :
I also add <> and <> for root and oracle.
I once had an Oracle consultant onsite; he wasn't too happy with pressing "Y" many times ;) Anyhow, you can override the <> with <>.
regards,
Thiery.

[Magdi KAMAL]

Hi Richard,

unix command needing a path ( as an argument ) to apply it's functions, behave like the following :

1. if first character in path is "/" then it applis the function using absolute path ( from / and down ).

2. if first character in path is not "/" then it applis the function using relative path ( from current and ... ).

3. You have to realy be careful using rm command.

I would recommand setting permessions on all filesystems to denny any unalerted rm commands from users. daily backups ( of curse Ignite Tapes ) could be highly appreciated in some circonstences.


The alias way given by James is good one ( but not against scripts ).

Magdi
Magdi

[Philip P. Hartl]

A simplier way was suggested in Unix GURU: Protect files in sensitive directories by
touching a file "-i" by typing "touch -- -i" in the concerned directory. Then any command using a "*" will see the "-i" in the file list and interpret it as an option. For example
rm * becomes rm -i file1 file2 file3 . . .

[James R. Ferguson]

Hi Richard:

I do the same as Thierry. In fact, I have interactive aliases for 'rm', 'rmdir', 'mv' and 'cp'.

With 'cp' I add '-p' since I generally want to preserve permissions and timestamps.

If the aliases get in your way, you can issue:

# unalias the_alias

Then the default is restored until either you define the alias or logout and login again.

Regards!

...JRF...

[someone_4]

Thoose are some good ideas I will have to implement something. Because that was just too close to rm /*

Richard

[Bill Hassell]

And one last comment: root's $HOME directory must be moved ASAP on all Unix machines if it is the / directory. Yes, HP ships it that way but no one rememebers why or has a any reason to keep it there.

On the other hand, everyone fears (or should fear) the rm -r * command. Consider this scenario for root (and DON'T do it!):

cd $HOME
cd /temp
rm -r *

The hapless sysadmin has made a very big mistake and has destroyed the entire system. All files will be removed. The problem is that there is a spelling error: /temp is not the same as /tmp and the sysadmin missed the small error message: sh: /temp: not found.

So no change was made and the rm command is now operating on the current directory ($HOME) which if not changed is: /

Suggestions: mkdir /root or mkdir /home/root. The /root directory stays with the root filesystem whereas /home/root moves to another mountpoint. Remember that root often leaves droppings (like bird droppings?) and can accidently fill / which is not good.

One other vote for the alias fixups (alias rm="/usr/bin/rm -i") involves another accident:

cd /home/billh
rm -r *
rm -r .*

Oops, although .* will remove those pesky 'hidden' files that start with . like .profile), the shell expands .* to also match .. and that's bad. The command will now remove the parent directory (/home) recursively. As many sysamins know, .* (that's dot star) matches things you aren't expecting.

Hint: to remove all dot-files (there's always several ways):

rm .??* (won't remove files like .a or .aa)

rm .[!.]* (works for all dot files)

[Ed Klemm]

I did a rm of a 1G file but bdf still shows the filesystem above 91%. How/When will I see the filesystem space drop.

[John Bolene]

If that file is still open by a process, the space cannot be freed.

[Eugen Cocalea]

Hi,

rm ./* is a piece of cake :)

One of my users, that had the root pass on its workstation, tried a rm -rf .* to remove the dotfiles. Well, he had a little surprised when he was 'warned' by rm that it cannot remove /dev/ and hitted ctrl-c. Well, /bin was long gone.

E.