Browser

Cut down on Linux command-line typing with these 10 handy bash aliases

The Linux desktop may have come a long way, but there are still times when you'll need to use the command line. Luckily, you don't have to type the same commands over and over. Jack Wallen shares some of the aliases he's used over the years to reduce the need for repetitive command-line typing.

The Linux desktop has come a long, long way, but there are still times when I have to use the command line. (I am a hardcore user, after all.) But even though I'm used to typing, spending hours upon hours with my fingers at the keyboard, I still grow tired of typing the same commands over and over. To reduce that tedium, I always add aliases to my .bashrc file.

What is an alias?

An alias is basically a shortcut for a command you place in your ~/.bashrc file. Aliases cut down on typing and can save you from having to look up a command. (If your memory is like mine, this can be a real boon!)

Aliases are set up near the bottom of the of the .bashrc file. You'll see a commented-out section that indicates where you should put them. The format of an alias is:

Alias NICKNAME='full command here'

The keyword alias must be used. The nickname is what you will type at the command line. Make this nickname easy to remember. The = sign must also be used. After the = sign, you enter the full command, including flags and switches, enclosed in single quotes. Once you are done, save the .bashrc file and open up a new terminal. I always find it best to leave the original terminal window open in case there are problems. In the new terminal, type the alias nickname and the command will run.

To get you started, I've compiled the following list of aliases I have used over the years to help make my command-line experience a bit easier.

Note: This information is also available as a PDF download.

#1: The ssh alias

This one should be a no-brainer for those of you who frequently secure shell into particular boxes. For this I add an alias like so:

alias server_name='ssh -v -l USERNAME IP ADDRESS'

Just change server_name to a memorable name for the server. Then, change USERNAME and IP ADDRESS to suit your needs.

#2: The ls aliases

Some distributions don't include some of the handier ls commands. Generally, I like to see full listings instead of just filenames. For that I always include this alias:

alias ll='ls -l'

Another handy ls alias is this:

alias la='ls -a'

#3: The rm safety net

I can't tell you how many times I have "rm'd" a file I shouldn't have "rm'd". To avoid this, I add this alias:

alias rm='rm -i'

Adding the '-i' flag it forces rm into interactive mode, which will ask you whether you're sure you want to remove a file.

#4: The more useful df command

This handy tool tells you how much space you have left on a drive. Only thing is, if you run the command by itself it replies in 1K blocks. Most people would prefer to see this in terms of MB. To make that happen, add this alias:

alias df='df -h'

Now, every time you run the df command, the information will be returned in a human-readable format.

#5: The nonstandard Firefox

Many times, I install Firefox in strange directories (or have more than one version of Firefox installed for testing purposes). For this, I will add an alias to start the correct Firefox. Say, for example, I have the beta of the newest, upcoming Firefox release installed, as well as the current stable Firefox. They are both installed in my home directory in different subdirectories. I will then add two aliases like so:

alias ff1='/home/jlwallen/firefox/firefox'
alias ff2='/home/jlwallen/firefoxb3/firefox'

Now I can start the stable firefox with ff1 or the beta with ff2.

#6: The bookmark alias

Speaking of Firefox, let's create an alias to open up it to a specific URL:

alias fftr='/home/jlwallen/firefox/firefox http://www.techrepublic.com'

This alias will open Firefox directly to the TechRepublic Web site.

#7: The constant editing of a file

There are certain files that I am constantly editing. For instance, when I used Enlightenment E16 (I now use E17), I was frequently editing the menu file ~/e16/menus/user_apps. Instead of constantly opening up a terminal and entering nano ~/.e16/menus/user_apps, I used an alias that allowed me to type emenu and start editing. I used this alias:

alias emenu='aterm nano -e ~/.e16/menus/user_apps'

Now, I just enter the command emenu (or I can enter that in the run command dialog) to open up this file in an editor.

#8: The apt-get update

There are numerous ways to use an alias to help you with apt-get. One of my favorite is to add this alias:

 alias update='sudo apt-get update'

I only need to enter update and will be prompted for the sudo password. You can modify this to suit your frequent apt-get needs.

#9: The rpm batch install

I like to do a lot of batch installing with rpm. I will typically dump a bunch of rpm files into an empty directory (created for this specific purpose) and run the command rpm -ivh ~/RPM/*rpm. Of course, an alias makes this even easier:

alias brpm='rpm -ivh ~/RPM/*rpm'

You have to create the ~/RPM directory and enter the root password for this to work.

#10: The long, arduous path

There are some paths that I often change to that seem to take eons to type. When I was working on the Afterstep window manager, I had to constantly change to the ~/GNUstep/Library/AfterStep/start to edit menus. After a while, you get tired of typing cd ~/GNUstep/Library/AfterStep/start just to get to the directory. So I added an alias like so:

alias astart='cd ~/GNUstep/Library/AfterStep/start'

Naturally, you can change that to fit your needs. This will save you a lot of typing.

So there you have it: a few simple bash aliases that will ease the load on your fingers. You can modify them to suit you, and they'll give you a good start on creating your own handy bash aliases.

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

42 comments
f18sim
f18sim

alias a=alias If you're on the same box all the time then not using aliases, functions, symlinks, and environment variables is just plain dumb. They all speed up all the mundane repetitive tasks that admins invariably have to do daily.

jmgarvin
jmgarvin

apropos is a great command, but man friggin' irritating. So, I made a nice little command called sman to ease my pain. The nice thing is I could feed the output of grep to apropos and REALLY get groving... VERY NICE! If it not success, I will be execute.

cboom
cboom

Great tips for easily running commands, including running the ls command with several options! Keep in mind that you can just type in: alias and press Enter to see your existing aliases. Most Linux distros have lots of default aliases already set up for users. And the aliases for the root user are usually different from the aliases for a non-root user! One thing that some people find confusing is that when they run a basic command, like the ls command, the output is different between the root user and a non-root user - when using the same distro. And the aliases in one distro are usually different from the aliases in a different distro. So, running the ls command as root and as non-root will likely be different in the same distro and running ls in a different distro may show something different again! You can have a look at a book for Linux command newbies - a Linux Commands training book - is being created and developed - daily - in a "blog to Linux commands book" blog over at: http://www.LinuxCommandsBookBlog.com and I welcome your comments, suggestions and Linux commands training questions. You can contribute to a Linux commands training book! You can sign up (by putting your email in the top right corner) to get regular blog updates by email or RSS - all free! You can also learn how to use Linux commands by watching free sample Linux training video tutorials at: http://www.iLearnLinux.com/Linux-Commands/ Thanks for the post! Clyde Boom, http://www.iLearnLinux.com The Easy Linux Training Guy ;) - Easy, self-paced Linux training - in Plain English!

silvestre.t
silvestre.t

ssh-argv0 in conjunction with a good .ssh/config can be very useful: if I have a server with a name like lnxweb, I have to connect with the user webuser, but for the other server, I must use myuser: vi .ssh/config host lnxweb user = webuser host * user = myuser someoption = blah blah :wq cd ~/bin (or everywhere in your path) ln -s /usr/bin/ssh-argv0 lnxweb You can even send a command: lnxweb -- date lnxweb -- "command | grep text | awk '{print $1}'" And did you check dsh? (it use ssh, and .ssh/config ...)

hi
hi

Never alias rm to rm -i. Otherwise you'll get used to it and when you switch machines you'll regret not having your "Safey Net"!

janusloki
janusloki

Oh, no. While the vast majority of these are perfectly fine, this one in particular is DEADLY- "alias rm='rm -i'" What happens when you move to another system that DOESN'T have that alias? What happens when you move to the production server to do "just a tiny little maintenance task"? Whoops. You accidentally typed rm. No big deal, right? It'll ask me, right? WRONG. You don't have the alias on the production server, and now you've just wiped out your ENTIRE /bin folder, or whatever. Sucks to be you. Clean out your desk and don't let the door hit you in the ass on the way out. The worst thing about aliases, IMO, is that they're silent. There's no way to know, short of checking the .bashrc file EVERY TIME you log in, that your aliases might have changed.

somoneontheweb
somoneontheweb

a simple one i use all the time for aliases alias ea='vim ~/.aliases_bash' #change vim for your favoutite editor #your name/location of the aliases file might be different , change that as needed. in the same vein # edit your bash functions alias ef='vi ~/.functions_bash'

cnd551
cnd551

My favourite is: alias update = 'sudo apt-get update && sudo apt-get upgrade'

jdclyde
jdclyde

For two reasons. One, if your not typing in the command/path, will you remember the command/path? Two, if you don't remember, what happens when you sit down at someone else's box that doesn't have that alias set? Shortcuts like this tend to come back to haunt you later on.

apotheon
apotheon

Since I use FreeBSD as my choice of primary OS, the default shell is csh or tcsh. I generally just use that for working at the command prompt, and use sh for shell scripts (since sh is everywhere, and doesn't disappear if for some reason I lose access to directories like /usr/bin). Aliasing in (t)csh is pretty simple, too. I just figured I'd mention the syntax for those like me who use it instead of bash for everyday work: [b]alias odate 'date +%Y%j'[/b] . . . in csh or tcsh is the same as: [b]alias odate='date +%Y%j'[/b] . . . in bash.

SublimeDre
SublimeDre

I didn't see any use of variables in this thread. Here's a good implementation of apt-get with shell variables. alias get='sudo apt-get install $1 $2 $3 $4 $5 $6 $7 $8 $9' With so much open source software this one comes in handy. Even more so when the software in question has dependencies. FYI... $0 is the command name, in this case it would be apt-get. Have fun!

Neon Samurai
Neon Samurai

That right there is a wonderful feature. By habbit, I was half way through moving the content too a word doc when I noticed the PDF link in passing. Thanks for making that a regular feature your articles. Now, I have to go check over the aliases recommended though I think Doug's above is the bit of gold which enables the other's.

doug.lewis
doug.lewis

I have this as an alias to help me remember what aliases I have set up in my .bashrc alias aka='cat ~/.bashrc | grep alias' This will print to the shell your alias commands quite nicely.

masinick
masinick

Aliases are typing conveniences, not crutches. If you are on another person's system, do not change a configuration file, such as a .bashrc file, unless you have permission to do so or you have your own account. As far as rm -i goes, well, I suggest you know what you have before you do something foolish. If you are prone to deleting files or directories inappropriately, first, it is always good to know where you are located in the file system at the time you perform any command. That is what ls and echo are for. If you are unsure of what you are doing, always do a pwd to list the location of the current working directory. You can create aliases for always listing and printing what you are doing. If you are prone to make mistakes, create an alias that will allow you to echo what you are doing before you actually do it. If you are just rushing and being careless, yes, you will make mistakes whether you use aliases or not. As you can tell, I do not buy the arguments about why not to use alias. Do not use it only if your management prohibits their use. Can they stop you from assigning an "alias on the fly" without putting it into a .bashrc or other resource file? Scripts use variable assignments, abbreviations, and all kinds of tools. No reason why interactive use should be any different. They are, however, no substitute or replacement for carelessness. Quit rushing so much that you do not think about what you are doing. Then alias can truly be your friend.

Neon Samurai
Neon Samurai

with urpm I can "urpmq fish" and get a list of all package names including "fish". It's handy for searching a package without leaving the cli. I've tried "apt-get search" and similar. Anyone have such a cli command switch? (I ask because I'll forget to take five minutes with a search engine later)

williamjones
williamjones

I've been supporting a bunch of researchers who use a Solaris server for their statistical analyses. They've passed around a .bashrc file that was originally created *years* ago by a gray beard, and when I started, no one understood what half the 30 or so aliases in that file even did. It took some time to revise that file, and trim it down and document only the useful aliases. One of the great things about using/supporting Unix-like OSes is that they've been in use for so long, you can find out *anything* you need to know with a simple Google search. That's not he case when everyone starts using--and expecting their support pros to anticipate--custom aliases.

jimacoski
jimacoski

I completely agree. Although alias use can cut down on time during sys admin/dev, becoming dependent on custom alias commands can make you much less efficient when working on a client's server (which is 90% of our job), which is why we encourage all of our developers and sys admins to make sure they are fluent in the standard commands. We also frown upon setting scripts on client's servers to set variables/alias values to make our job easier, as it's their hardware, not ours... Keeping that in mind, these are still useful to know :o) -Jim

masinick
masinick

You mentioned using alias get='sudo apt-get install $1 $2 $3 $4 $5 $6 $7 $8 $9' Though I believe it has been mentioned before, it bears repeating, you can use $@ to replace a list of arguments. For example, alias get="sudo apt-get install $@" works well.

masinick
masinick

alias inst="sudo apt-get update && sudo apt-get install $@" Also, this one is useful: alias ug="sudo apt-get update && sudo apt-get dist-upgrade" and this one to make sure my network is functioning correctly: alias ya='ping -c 3 yahoo.com'

techrepublic.mt9z
techrepublic.mt9z

SubmileDre, what shell do you use? For bash, the alias replaces just the first word of the command. Any arguments will be simply appended to the alias replacement text. In your example, if you type "get foo", bash would see "sudo apt-get install $1 $2 $3 $4 $5 $6 $7 $8 $9 foo", and presumably you invoke your shell with no arguments so the $N variables are empty. Anything requiring variables requires functions. I too have an "ll" alias. I also have an "lt" function that finds only the most recent files: lt() { ls -lt ${1+"$@"} | head -20; }

masinick
masinick

The alias definition alias aka='cat ~/.bashrc | grep alias' is a good one. But you can also store all of your alias definitions in the file .bash_aliases, and have logic: if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi Then you can put that alias into ~/.bash_aliases and change it to read alias aka='cat ~/.bash_aliases | grep alias' or simpler yet alias aka='grep alias ~/.bash_aliases'

paul.cobbaut
paul.cobbaut

Nice tips, but i prefer to put them in my ~/.inputrc (linked to a function key) sample: ~# grep apt .inputrc "\e[17~": "aptitude update && aptitude safe-upgrade\n"

speculatrix
speculatrix

I use the following aliases quite frequently alias psg='ps -ef | grep -i' the above makes it easy to search for a process, just type "psg firefox" for example. alias h='history | tail -80 | more' to list previous commands the above two, apart from "ll", are the first things I add to .bashrc on a new machine.

apotheon
apotheon

You don't need an alias for that, and you don't have to use cat and grep. Just typing in [b]alias[/b] will give you a listing of what aliases you have set up. Of course, the [b]alias[/b] command gives you a listing of all aliases you have, regardless of whether they're in your shell's rc file or not, so if you're specifically looking for aliases in .bashrc, your option is still what's needed. . . . but what's usually needed is something like the output of the alias command with no arguments: [b]$ alias alias ls='ls --color=auto' alias fodate='date +"%Y%j %a %T %Z"' alias ooo='openoffice.org'[/b] . . . like that.

pgit
pgit

That's what I call 'elegant.' Here's one I find handy. A lot of Linux using clients avail themselves of a central PIM server which they either use on their main use machine or access remotely over ssh. When you log in and forward an X app over ssh the .ICEauthority files in the user's /home gets touched, and the remote user could be anything, "nobody" for instance, or it could be the right user but with a different UID. Whatever the cause, touching this file remotely causes a subsequent local login attempt to fail on the main box. The answer is to delete the .ICEauthority files in the user's /home. So I have aliased the command: rm -f /home/vina/.ICE* (note it will remove any/all .ICE... files) The alias I use is "melt." (ICE... get it?) All these users have the alias on board, and after having had numerous problems have learned to type "melt" just before logging out from a remote machine. And I mean a LOT of problems. Simple fix and easy for the end user to remember.. including why they need to do this.

Tony Hopkinson
Tony Hopkinson

irrelevant. Having one is what's important. We've all deleted some thing we shouldn't hab=ve at least once. Much of our job is coming up with processes to avoid doing so and dealing with the fall out when 'we' haven't. Checks or avoidance aren't for careless people, they are for everybody, because we are all capable of being careless on occasion. Denying that is careless.

apotheon
apotheon

Try [b]apt-cache search search-term[/b] instead. The [b]-get[/b] commands are used for anything that involves contact with the remote server, including updating the local cache of the available packages list (because you have to get the update from the server). The [b]-cache[/b] commands are used for interacting only with the local cache -- which includes searching it, getting package information from it, and so on. I'm not really sure why the "clean" commands are associated with [b]apt-get[/b]. I've never really understood that quirk.

apotheon
apotheon

I obviously don't go adding aliases to clients' systems, but I use a few on my own. Of course, I don't use the kind of aliases described here. A few I have in my .tcshrc file (assume each of these says "alias" before it): com 'cd ~/svn-local/apotheon/com' eins 'ssh -p ' fdate 'fodate; date; date -u' fodate 'date +"%Y%j %a %T %Z"' hydra 'ssh -p ' itsec 'cd ~/doc/essay/itsec' odate 'date +%Y%j' ooo 'openoffice.org' pget 'getmail --getmaildir=.pgetmail' pmutt 'mutt -F ~/.pmuttrc -f ~/pMail/Inbox' proxy 'ssh -D -p ' rget 'getmail --getmaildir=.rgetmail' rmutt 'mutt -F ~/.rmuttrc -f ~/rMail/Inbox' udate 'date; date -u' I've deleted a few to protect the guilty and avoid too much redundancy, of course, and elided specific ports and addresses. The mutt aliases allow me quick and easy access to different accounts via mutt, obviously. The cd aliases (both those listed and those I skipped) are for commonly used directories that I don't want to type all the time and are particular to the working environment on my laptop. Notice I don't use any of the typical nonsense that Linux distributions like Ubuntu and Fedora tend to assume people want -- like aliasing rm to "rm -i" and those silly la, lb, lc, et cetera, aliases for ls. I tend to keep basic commands in their default forms, for much the reasons you have described for not using aliases.

Neon Samurai
Neon Samurai

alias get='sudo aptitude install $@' If your using apt-get, your already working with command line package managers so that's not an issue. I'd suggest using Aptitude rather than apt-get though. Aptitude will keep track of if a package was requested or intstalled as a dependency to one that was requested. When the requested package is uninstalled, any dependencies not required by other programs will be uninstalled with it. When you search with Aptitude, it will indicate if a packag is installed or not. Apt-get, by contrast, does not keep track of reason for package installs. later, if you uninstall a program, apt-get will not remove dependencies no longer required by other programs. I don't much care for the interactive aptitude but you can put any of the apt-get switches behind it and work the same way as apt does now: aptitude search charstring - returns package names where charstring is in the name or description. aptitude install packagename - install the package and relevant dependencies. aptitude purge packagename - uninstall including all related config files aptitude remove packagename - uninstall but don't remove all related config files generated outside of the original package aptitude update && aptitude full-upgrade That one updates your repository package list and presents a list of available packages a-la "full-upgrade". You can alternatively do "safe-upgrade". It'll get you all the benefits currently enjoyed from apt-get plus better package management.

apotheon
apotheon

Just entering "alias" at the shell prompt should list your aliases.

Neon Samurai
Neon Samurai

So the original issue was that the Maemo package manager displayed available updates. When the updates where selected and installed they failed with an error that the previous version was required for the update. This is a bit confusing being that the previous version was already installed by the original OS image. The same issue pops up in Maemo 4.1 (Diablo) where one of the maintainers explains the issue. If I understand it correctly; the new version package is looking for the previous version but as part of the new repository. The older version is installed with the original OS image listing a different repository source. The older package version is valid as is the new package version but the new version does not recognize the old package as valid. The solution, manually install the two packages in question apt-get -f install newpackage1.deb newpackage2.deb Answer some scary warnings about missing dependencies or validations during the update process. Continue merrily on your computing way. The issue in this case was easily fixed once I spotted how in the forums. I just loved that the original developer actually posted to say; "hey, this was my fault. I screwed up the package dependencies. I'll get it fixed but until then, update those packages by doing this; apt-get -f install ..."

Neon Samurai
Neon Samurai

The specific case is the maemohackers repository for Maemo no the N800. I have been limited to doing manual updates package by package in the GUI because "apt-get update" fails with a cert issue. I want to type "apt-get -f udate" so it warns me but does not halt all the good repositories. (I guess it's time to go through and disable it for the update) Where this a core server system or similar security and importance, I wouldn't be bypassing repo validation but for my own hack-a-bout box it's a hinderance to be resolved.

apotheon
apotheon

"[i]I know and trust the repository so is there an 'ignore invalid certs' command switch I'm missing?[/i]" Part of the reason for those certs is to give you a warning in case someone has somehow managed to direct your requests to a different repository server with a forged certificate. You need to resolve the issue, if you want to maintain your security -- not ignore it.

Neon Samurai
Neon Samurai

Quick and simple list of the key commands. Sure, I stumble on this after I ask my question. :D http://lena.franken.de/linux/debian_and_vserver/commands_to_install.html One more question though. I have one machine where I run apt-get update && apt-get upgrade but the update fails part way through telling me the repository has an invalid certificate. I know and trust the repository so is there an "ignore invalid certs" command switch I'm missing?

Neon Samurai
Neon Samurai

Who knew that not being able to search package names from the cli would feel so restricting. Now to start rebuilding my server VMs on Debian. (BSDs are stage three of helping a client learn Unix) Besides, I have to give this Apt stuff a go and see why those who love it, love it a lot.

jdclyde
jdclyde

Like I said though, SCO was horrible for burying things in long obscure locations. I also like the sym links for when a user has to get to specific information to work with. The link takes them from their home directory to where the data is located, and ONLY to that data.

jdclyde
jdclyde

It isn't Directories, it is "folders". Who ever heard of a "folder structure"? :0

apotheon
apotheon

You must be hating Vista and KDE4 then I would if I had to deal with them more. Luckily, I'm smart enough to use something else. The "future" apparently is the physical location of data doesn't need to be known to the user. I've never liked software that tried to keep me ignorant. I have been giving the "new way" a try, with both Vista and KDE4... I just don't see it. I suppose someone just starting out with computers nowadays will 'get it' and never know any different. Well . . . I get the tags approach, but it's really suboptimal for a lot of cases. As such, even if I find some value in using tags for organization from time to time, hierarchies tend to be far more useful in general. Frankly, I'm pretty sure that tagging is going to turn out to be a short-term solution to a long-term problem, just filling in the gap until a new generation of search technology matures. Tags are, in short, a manual way to accomplish what should be an automatic task. BTW windows default directory structure plain stinks. Always has and apparently always will. It starts with a gap (blank space) in the initial directory and it's all down the tubes from there. I'm convinced M$ does this to make cross-compatibility with Linux/Unix scripting that much more a PITA. That's always a possibility.

pgit
pgit

You must be hating Vista and KDE4 then, keeping things straight in a hierarchy of directories as you do. The "future" apparently is the physical location of data doesn't need to be known to the user. KDE4 has switched from the most excellent file browser ever devised, konqueror, to dolphin, which claim to fame is the display of tags and metadata. I doubt I will ever stop thinking of directory structures. It's just too logical to abandon. I have been giving the "new way" a try, with both Vista and KDE4... I just don't see it. I suppose someone just starting out with computers nowadays will 'get it' and never know any different. BTW windows default directory structure plain stinks. Always has and apparently always will. It starts with a gap (blank space) in the initial directory and it's all down the tubes from there. I'm convinced M$ does this to make cross-compatibility with Linux/Unix scripting that much more a PITA.

apotheon
apotheon

I have my user directory organized the way it is for a reason -- and that's because of the desire for a hierarchical arrangement of directories that makes logical sense to me. If I start littering my base user directory with symlinks, I might as well just put all my subdirectories in the user directory, directly, rather than using a hierarchical organization scheme. No . . . I think I'll stick to using aliases to move around quickly, so I can keep my logical hierarchical organization, at least within my user directory. Aliases are particularly useful in cases where I know I'll only be regularly visiting a particular directory for a little while; I just create an alias to take me there, use that until I no longer need to visit that directory regularly, then remove the alias. On the other hand, if there are a couple of directories I will use regularly, pretty much indefinitely that have really long system path names, I'll use symlinks for those, as long as the symlink path ends up fitting logically into a given directory structure hierarchy. If it's not a system path (i.e., something that's there for compatibility reasons or something along those lines), and I'm tempted to make a symlink to make it easier to access and the symlink location is a logical one within the directory hierarchy, I just take that as a sign that the directory is in the wrong place and needs to be moved.

jdclyde
jdclyde

One of the first things I learned when working with SCO was to love a good symbolic link, because of the sometimes very deep and long path names. It is nice that modern *nix OS's have gained a clue, as to not thinking your web or ftp server should be 7 directories deep.