SUMMARY:Creating alias in bash ...

Date: Thu Mar 23 2000 - 23:11:49 CST

Hello sun managers,

Here's the summary:

The original question:

Why does the following command alias not work in bash
alias rm='! [ -d ~/trash ] && mkdir ~/trash;D=`echo $*|sed s/-r//`; \
 /bin/mv $D ~/trash'

wherein the alias was intended to move deleted files to
$HOME/trash directory instead of actually deleting them.

I ended up using a shell function as suggested by Kevin Sheehan.

Thanks to the following for responding: (Kevin Sheehan {Consulting Poster Child}
"Gordon Hopper" <>
Chet Ramey <>

Their replies were:

do it as a shell function - that way you can manipulate the args and
not have to use sed (which saves a fork/exec at least). And you can
export functions (so they follow on in the env) unlike aliases.
rm() {
if [ -d $HOME/trash ]; then :; else mkdir $HOME/trash ; fi
for i in $* ; do
case "$i" in
-r) ;;
*) D="$D $i" ;;
mv $D $HOME/trash
export -f rm
>From "Gordon Hopper" <>
You could replace /bin/rm with a script which does what you want. Rename
to rm.orig or something like that so that you could still call it if you
want to.

Be aware that this might have implications on system scripts and other
which call /bin/rm to do their work. You might want to put something in
/usr/local/bin/rm and make sure that comes first in the path for user

Or even alias rm='/usr/local/bin/rm.trash', where rm.trash is your script.

BTW, I don't see anything wrong with your alias, but it doesn't seem to
for me either.

                I get:
                $ touch asdf
                $ rm asdf
                mv: asdf: rename: Not a directory

And if rm a directory, it moves the trash into that directory. As if the
arguments to mv were reversed. You can see that they are reversed if you
change '/bin/mv' to 'echo /bin/mv'. Why is this? Please let us know if
figure it out.

The real interesting thing is that
echo /bin/mv $D $HOME/trash/
echo /bin/mv $HOME/trash/ $D
print the same thing.
If I were doing what you want, which appears to be replacing rm
with something that saves files somewhere instead, I would *not* do it via
alias - too many ways to defeat it, intentionally or unintentionally.
I'd move away the rm command in /usr/bin (or wherever it happens to be) and
in its place a script that does what you want. By making it a script, you
exactly control what it does regardless of the user's environment settings
which might be what is messing up your alias.

Do the same thing as your alias in your script, only add PATH variables and
don;'t rely on anything in the environment (other than the $HOME variable).
will be easy to deal with the -r flag in the script - use it or ignore it.
be sure you handle all of the normal rm functions appropriately.

On the other hand, telling the users that they can no longer use the -r
flag is
really taking a lot of functionality away from folks.

On the third hand, why not look at this as a process of education - teach
people what rm does (deletes files) and let them screw themselves if they
remember that.

On the fourth hand, if your users are experienced unix users they will
not look kindly on your messing with the rm command. If they are
then just provide them (via script) a new command - say "del" -
that does the save function.

Finally - let me emphasize that what you are doing is dangerous - your are
trying shield people from making mistakes by removing functionality and
replacing it with something that only sort of works (doesn't allow for
removes recursively) - you may serve them beter in different ways - be
>From Chet Ramey <>
What do you expect it to do?
Your alias operates on the shell's positional parameters ($*). Aliases
don't take arguments. You should probably use a shell function instead.

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:05 CDT