23

For example, a common alias I've seen in the ~/.bashrc file (or equivalents) is

alias rm='rm -i'

However, I've seen people recommend against this because

  1. the alias might not exist on another system and since you've become careless with rm, you inadvertently delete something important. [1]
  2. by using this alias, you in effect train yourself to type y or yes after every rm command, which defeats the whole purpose.

Are there other reasons to recommend against this? Might some programs simply make calls to rm instead of \rm, and aliasing over it could cause problems for them?

I use rm simply as an example, but I've seen other commands like cp or mv covered by aliases as well. Personally, I'm slowly training myself to use an alias like this in place of rm -i:

alias trash=`mv -v -t $HOME/.Trash`
Community
  • 1
Ricardo Altamirano
  • 829
  • 5
    Every time I trip over a system with a default alias of rm -i, it trains me a little more to automatically add the -f flag. – Jander Mar 06 '13 at 01:34
  • You can alias rm -i to anything you want. Such as del, irm, etc. You don't need to alias it to rm. This circumvents point 1, and by selectively using del or rm depending on what you want, you also circumvent point 2 to some degree. – Martin Tournoij Mar 06 '13 at 14:49

6 Answers6

12

Assuming that you're using bash, this should not cause problems for scripts, as non-interactive bash shells do not source ~/.bashrc or ~/.bash_profile (which is likely either where your aliases are placed, or is the first step to sourcing your aliases in another script). It may, however, cause problems if you are sourcing scripts:

$ alias echo='command echo foo'
$ cat > script << 'EOF'
> #!/bin/bash
> echo bar
> EOF
$ chmod a+x script
$ ./script
bar
$ . ./script
foo bar

Your question covers most of the general concern around aliasing over existing commands, the major one being that unfamiliar environments which appear at first glance to be the same could potentially produce wildly different results. For example, aliasing rm to rm -i has good intentions, but is bad in practise for the reasons you state.

Chris Down
  • 125,559
  • 25
  • 270
  • 266
8

"Are there other reasons to recommend against this?"

Of course:

(3) Because one day I hope to add to the foundations built by the [-----------] and paranoid people who chastise others for aliasing standard commands, even though aliasing standard commands is, well, standard.

Seriously though, these are just caveats. If you trust yourself not to fall into any of those pits of doom, then just beware and go ahead.

Personally, I alias very few standard commands; I use slight variations because I am, just a bit, paranoid and anal retentive. But one good use I've found for this is with regard to systems where I often log in as root or another user, and there are some things I don't want to accidentally/lazily run as root:

alias irc="echo \"No you don't!\""

or 

alias irc="su irc_user"
Community
  • 1
goldilocks
  • 87,661
  • 30
  • 204
  • 262
6

As an extreme example, let me just alias a standard command to illustrate why aliasing standard commands can be harmful:

alias ls='rm'

Obviously, this is bad because it would cause a nasty surprise some day. Likewise, replacing standard commands with aliases will eventually lead to an unfortunate surprise when you least expect it.

But let me present a common scenario which will happen to nearly every Unix admin as they advance in their career:

Someday in the future, you will start a new job and will work on a new system which was set up by others. It will be three o'clock in the morning on Saturday and you aren't thinking straight and are prone to make mistakes. Your standard environment will not be available. In fact, you are root.

Given this, are you going to remember that rm is not aliased to rm -i? Are you going to check for your special aliases every time you log into the box? If you change root's environment, will your coworkers be happy with your change?

I am honestly on the fence about this. I have worked on thousands of systems in my career, and if I did modify the environment on all of these systems it would be hard to see the value.

Aliasing rm to rm -i is very common and I have seen it prevent many problems, but it has also caused many surprises and hours of extra work to recover accidentally deleted files.

So now I try to avoid aliasing common system commands. Instead I use aliases and functions to do things which the shell can't easily do. What I tend to do now is attach an extra letter to the alias, like:

# List long, with color or special characters, depending on OS
alias  ll='ls -l'
# Long, with metacharacters, show dotfiles, don't show . and ..
alias lll='ls -lA'
# Long, with metacharacters, show dotfiles, show . and ..
alias lla='ls -la'
# List just the dotfiles
alias  l.='ls -l -Ad .????*'

# Useful greps
#alias hgrep='history |grep ${*} |grep -v $$'
alias greph='history |grep ${*}'
alias grepp='ps -ef |grep ${*}'

### Highlight some text.
# From http://unix.stackexchange.com/questions/366/convince-grep-to-output-all-lines-not-just-those-with-matches/367#367
highlight () { grep --color -E "$1|$" $2 ; }

And perhaps I really should get rid of my final alias, because adapting to new practices takes time:

# For safety!
alias rm='rm -i'
Stefan Lasiewski
  • 19,754
  • 24
  • 70
  • 85
  • 8
    Remembering the flags for ls might be more convenient than remembering ten aliases. – Bernhard Mar 05 '13 at 19:08
  • Very true. And in fact, I rarely use these aliases any more. I am not sure why I still have them, other then the more complicated aliases (and functions) were hard to figure out and are good for reference. For simplicity I should probably remove them. – Stefan Lasiewski Mar 05 '13 at 19:10
  • The "illustration" (first example) isn't really useful. That's clearly malicious, and we know the booby-trapping a system can be harmful. Your rm -> rm -i example is much better. Another good one would be one that aliases rm to put things in a ~/.trash – derobert Mar 05 '13 at 19:29
  • 1
    @Bernhard: True, but the aliases are faster to type. (But ten are too many regardless.) – Emanuel Berg Mar 06 '13 at 00:56
  • 2
    @StefanLasiewski: Hint: never remove stuff that doesn't show, for purely aesthetic reasons. Let them remain unless they disturb you actively. It is such a fast act removing stuff after spending hours setting it up; and if you ever regret it, you feel like an idiot for not just letting them be. – Emanuel Berg Mar 06 '13 at 00:59
5

There are more dangers to it.

For example, if you use shell-command in Emacs, you might think you get "your" command (or alias, but you don't have to strike an ls alias in a terminal that many times before you forget all about setting up the alias, thinking of it as any other command...) -- in fact (back to Emacs), you get the (unaliased) command. Emacs will execute it without problem, so you might even be blind to what just happened!

As for different computers and/or systems, if you think it is too tedious to setup individual .rc files for them all, you can just have one such file, but with if clauses to tailor.

For example, instead of assessing each function when you write them, just when you experience problems with any of them, add them to the "black list", last:

if [[ `uname` == "SunOS" ]]; then
  unset -f mic cpkeep mcp mcph cpindex cpconf # not for Solaris
fi
Emanuel Berg
  • 6,903
  • 8
  • 44
  • 65
3

Renaming standard commands by aliases (i.e., the rm=rm -i) stuff certainly can lead to suprises where the alias isn't available. I prefer not to use such, and (by several bitter, bitter experiences ;-) I've become acustomed to reading each command twice, and if it's rm or mv or anything else potentially destructive thrice. And such aliases lead to automatic "rm foo" ENTER "y" Oops!! anyway (and cost an extra keypress each time).

But that's just me. If you don't expect to run in alien environments (other machines, other users, ...) and you can install your favorite aliases wherever you are, go wild. Unix is famously known to give users more than enough rope to shoot their own feet.

vonbrand
  • 18,253
0

The other answers are good, but they all only look at how it affects you.

Let me turn @Stephan Laswieski's answer on it's head a bit.

Assuming you're not omniscient, you may need to have someone else work on your user account or advise you as to how to do something.

Then, when they do something or tell you to do it, it may not work as expected.

At best,you'll have to waste time explaining to them what happened (if you're right there and can remember or figure out that the alias is what caused the problem).

At worst, see a twist on the example in one of the other answers: alias ls='rm -rf'.

Joe
  • 1,368