• entries
  • comments
  • views

command line apps



artv61 ("evilAzimuth") asked me the other day in IRC if I had a link to a site that listed and explained some of the really essential command line applications -- one that might help a new Linux user learn the command line. I thought that I did, but then realized that actually the source I was thinking of was the O'Reilly Linux Pocket Guide or Linux Essentials or something like that, and was not online but on a book shelf somewhere. While I would still recommend that as a source of good basic commands to know, I figured there ought to be one online as well.

Yes, there are probably other lists like this online but first of all, I couldn't find them and second of all, this one will be better.


Foreground, brings a backgrounded process back to the front. How is this used? If I'm in vim (which I am, right now) and I need to get back to a bash prompt so I can check something in the fg manual, I can hit control-Z to send vim to the background (vim then becomes "fg 1"). Now I can check the man page, and I could control-Z the man page when I'm finished (it will become "fg 2") and again get a prompt. So now I can type in "fg 1" to get back into vim and resume typing, or I could type fg 2 to get back to the man page to look at that again. Go ahead, try it!


Lists currents jobs in that console. This list will contain all the apps you've sent to the background with control-Z and can now bring back to the foreground with fg.

bash$ jobs[1]   Stopped                 irssi[2]-  Stopped                 man fg[3]+  Stopped                 vim foobar.txt


Just learn ls and all of its many many view options. ls -alh and ls -m and even ls -FahGsilt and all that stuff.


The unix command everyone loves to talk about when demonstrating "how cryptic unix is", grep is one of those cool commands that you'll use every day. Of course, it searches for a string. Try it with a -i for case insensitivity!


At some point you're going to have to modify ownership of files. You will probably also have to modify them recursively.

chown -r klaatu:users ../../foobar/ 

That command would change ownership of all files in the foobar directory to klaatu=owner and users=group. That will give me, as Klaatu, the right to do whatever the Owner is permitted to do to that file.


Modify permissions of a file for User, Group, and Others.

There are different ways to set this, and it behooves you to learn the alphabetic method as well as the mathematic.

But the easiest way to do it is just like this:

bash$ chmod gu+rx foo.txtbash$ chmod bar.txt go-r

The first command would grant Read and eXecute perms to the Group and Others

The second would revoke Read access to Group and Others

...and keep in mind that where foo.txt and bar.txt reside will effect whether the Group and Others can get to them, as well; if the files are nested in a directory with 700 permission (Read Write and eXecute for User ONLY) then no matter what kind of permission you give other people, they won't be able to access the file because it's in your home directory and they can't get through the door, much less read or write or execute a file you've given them.

tar and gzip and bzip and zip

A lot of ways to compress your files. Each with their own special syntax. Can I break it down easily? Let's see...

tar cf archive.tar foo.png bar.ogg --> tar's foo.png and bar.ogg together into a archive.tar

tar xf archive.tar --> un-tar's archive.tar into foo.png and bar.ogg

gzip archive.tar --> gzip's archive.tar into archive.tar.gz

gunzip archive.tar.gz --> un-gzip's archive.tar.gz into archive.tar

tar xzf archive.tar.gz --> un-gzip's and un-tar's archive.tar.gz into foo.png and bar.ogg

bzip2 archive.tar --> bzip2's archive.tar into archive.tar.bz2

bunzip2 archive.tar.bz2 --> un-bzip2's archive.tar.bz2 into archive.tar

tar xjf archive.tar.bz2 --> un-bzip2's and un-tar's archive.tar.bz2 into foo.png and bar.ogg

zip archive.zip foo.png bar.ogg --> zip's foo.png and bar.ogg into archive.zip

unzip archive.zip --> unzip's archive.zip into foo.png and bar.ogg


Well, you have to know ifconfig these days. If you want to get onto a network, including the Big One (www), you will end up looking at ifconfig. It will give you your IP address, the broadcast domain, the MAC address, and so on, of all your network interfaces. Very important stuff. You can also bring up or down the interfaces with ifconfig <interface> up (or down). And more.


This seems to be fairly Linux-specific, because it's not in Open Solaris or any of the BSD's I've tried, or that bastard stepchild, OS X. But iwconfig gives you lots of ifconfig-style commands for wireless interfaces. Commands like:

bash$ iwconfig wlan0 essid freePublicWifi

...although connecting to an open network called freePublicWifi might be something to be careful about......


...that magical last step of getting online via a text console; invoke dhclient to probe the essid you've linked your interface to obtain an IP Address via DHCP. Essential if you askew Network Manager or wicd and so on.


You can sit there and fg/jobs things in the foreground and background, or you can switch between virtual consoles with control-alt-FunctionKey ... or you can install and learn screen. Screen will allow you to create new shells all in the same, well, screen -- and then switch back and forth between them all. And you can even switch to one of those screen sessions remotely. That is, if you were running screen at home, and then grabbed your eeePC (or Acer Asp1re or whatever) and went out to a cafe to work, you could jump online and ssh into your box at home, run a screen -raAD, and you'd be using your terminal session that you just left at home, switching back and forth between irssi and alpine and mplayer and all the rest. Really neat.

I have my profile in Konsole set so that when I start Konsole, instead of running /bin/bash, it runs /usr/bin/screen (well, along with a few other commands, but not relevant to screen) -- so I'm automatically screen'd when I start any terminal session in KDE.


Again, this is kind of specific to Linux but the idea is typically the same across *nix systems. It stands for Make FileSystem, and usually has a number of variants like mkfs.ext2 or mkfs.ext3 or mkfs.vfat or whatever. I usually type in just the command first and let its built-in help guide me:

bash$ mkfs.ext3Usage: mkfs.ext3 [-c|-l filename] [-b block-size] [-f fragment-size]        [-i bytes-per-inode] [-I inode-size] [-J journal-options]        [-G meta group size] [-N number-of-inodes]        [-m reserved-blocks-percentage] [-o creator-os]        [-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]        [-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]        [-T fs-type] [-U UUID] [-jnqvFSV] device [blocks-count]bash$ mkfs.ext3 -L gortdrive /dev/sdb/dev/sdb is an entire device not just a partition!  [O]k?

...and this will create an ext3 drive from /dev/sdb and the drive will then show up on my desktop as gortdrive.

mount and umount

mount /dev/sdb /media/zip --> mounts a drive that you have plugged into your usb port at the /media/zip location in your filesystem (yes, I use "zip" because it's easy to type and remember...and no, it's never really a zip drive)

umount /media/zip --> unmounts /dev/sdb from /media/zip ... as long as you are not IN /media/zip or using a file that is located there.

Granted, if you're running X then probably HAL is going to do all of this for you. But if you're not, you might need to do this manually.

Getting the /dev/ naming scheme down took me a while, at first. I'm still not clear on it all, mainly because I never pay attention to what's inside my computer...but I guess I have an IDE harddrive so it's /dev/sda and its first parition is /dev/sda0 and its second partition is /dev/sda1 and so on. If I plug in an external drive, the first drive I plug in is /dev/sdb, the second drive will be /dev/sdc, and so on. This leaves the dvdrom drive, which has always pretty much been /dev/hda because, I suppose, it's on another bus entirely. Luckily, the /dev/hda is usually linked to a generic /dev/cdrom so quite often I don't have to worry about it at all. I wish I knew the trick to easily figure out these names, but I still don't know the trick, I'm just at the point now where I kind of just know it regardless of what machine I'm sitting in front of. But sometimes there will be a surprise curve ball thrown in for fun; like the Apple TV I'm hacking away at to get Linux onto....it sees the external cdrom drive I'm using to boot from as /dev/sr0 -- which is a SCSI cdrom interface, but obviously it's not really scsi but somethign emulating scsi...I think IDE does that, but the drive is plugged into a usb port, which is fine, but how is one supposed to know that without googling for "what is the external cdrom drive called in appleTV whilst hacking linux onto it"

Well maybe someone will comment on this post and explain it all.


A quick and handy way of ejecting a disc from your dvd drive. eject /dev/cdrom

There may be other uses for it, I'm not sure. I just use it for the optical media drive.

This will surely be deprecated any day now. Down with optical media!!


Directs output to an additional place... so if I wanted to do a netstat but wanted to record the output of it to a local document AS WELL AS see the output on my screen, I would tee it to a file like so:

bash$ netstat -veN -A inet -c | tee netstat_070709.logtcp      185      0       wsip-98-174-208-105.hr:ircd CLOSE_WAIT  klaatu     107890tcp        0      1       p3slh056.shr.phx3.secu:http SYN_SENT    klaatu     114528tcp        0    454       p3slh056.shr.phx3.secu:http ESTABLISHED klaatu     114421tcp      329      0       simmons.freenode.net:ircd   ESTABLISHED klaatu     107044

...and this display would continue until I cancelled it. And then I could look at the file netstat_070709.log and, sure enough, I'd find that all the netstat data had been logged therein.

all the other typical unix commands

Come on, I'm not gonna sit here and expound the virtues of text jockeying in unix. go read a book on it. cat, redirects, pipes, echo, more, less, tail, and all that good stuff...learn it all!

your office app...

vim or emacs

You need to learn one of these two, or both, text editors. It will help you edit config files, it will get you closer to the command line (I'd have never learned the fg trick if I wasn't living in vim all day, realizing that I needed a more efficient way of :wq and then re-opening vim <path/to/document> all the time), and it will give you keyboard skills you can re-use in BASH (emacs) or ZSH (vim).

How do you learn these apps? both have tutorials on your computer; do those, then start living in them. Resist the urge to open up Abiword or OpenOffice or whatever, and just start using a real text editor.

your web browser...

lynx or links or elinks

Textual web browser. A real life-saver when you're flying along without X and suddenly you realize that you need to check something on the great wide world web. Start up one of these handy text-only browsers and surf away. If the site doesn't work with an elinks-style browser, then you probably shouldn't be taking time away from your work to go look at it because, as we all know, web 2-point-oh is for hipsters who never get any work done.

your media players...


Want music whilst you work? Invoke mplayer for all the music you could ever want to hear. You can also use it to watch videos...although not without X. Well, you might be able to watch a video as ascii text or something, but I digress...

your image manipulation program...

image magick

A graphics processor; one I use quite often when doing graphic work. It will take your GIMP'd RBG png's and translate them to CMYK pdf's with alacrity and ease. And it does a lot more than that, too. Best way to find out what all it can do is to just go to their site: http://www.imagemagick.org/script/command-line-options.php because they try to fit it all in a man page but...there's just SO MUCH!

your audio editor...


An audio normalizer with a level and gate to maximize audio contrast and adjust average perceived volume. You may have heard podcasters talk about a little app called Levelator, a non-free Python app that breaks every time anyone upgrades their Linux OS. Well, this is the free non-breaking version of that, I guess. (It's actually the other way around, I think; Levelator is the non-free breaking version of normalize, but whatever...)

sox and play and rec

sox is a swiss army knife for transcoding audio, or editing audio, or mixing audio.

play is sox's play module.

rec is sox's record module.

your video editor...


For transcoding videos and audio (with the -vn tag) -- very very handy. I use it many many times a day, every day...but then I'm a podcaster and video editor...

your internet chat...


Not just a badge of coolness in IRC, but the best way to IRC. When I first started signing onto irc servers, I literally couldn't figure out what to do until I started on irssi. Then, suddenly, it all became so obvious. I've done a few quick-starts on irssi on my podcast, The Bad Apples, but here it is again:

bash$ irssi --nick klaatuirssi > /server irc.freenode.netirssi > /join #linuxcranks

...and then start chatting. Politely. Don't forget to say "hi!" to notKlaatu

GNU freetalk

This is a jabber client, so you'll probably want to see finch (thanks, threethirty, for letting me know about that one) if you use or need to chat with AIM or other non-jabber/xmpp accounts. I do not, so I use the really swell GNU freetalk, which is a simple command line prompt with irssi-like syntax. I am not a heavy user of instant messaging these days, so how well it holds up to, say, 20 simultaneous convo's I cannot attest, but it certainly works great for my needs.

your email client...


Cuz I'm just not cool enough to use mutt, I guess. I tried mutt but I'm not knowledgeable yet to understand THAT much about MTA and MUA and stuff like that, so I'm gonna have to hold off on it. Until then, alpine is my dream email client and the one I have open in the background (remember fg?) or in a konsole tab ALL the time. It takes a bit of setting up, but there are great HOWTO's on alpine on Hacker Public Radio, by me, ready for your enjoyment. It covers Alpine, IMAP, and GPG...pretty much all you need for a very nice alpine setup.


What's inside your computer? Find out with lspci; it'll tell you all the important stuff on the inside of your computer, so you can find out what drivers you need to go look for, or whatever.


What is going on with the USB ports in and around your computer? Find out with lsusb; it'll tell you the ports (internal and external) and if anything is connected to them.

./configure and make and make install

Simple as 1-2-3. ./configure && make && su -c 'make install' will compile and install an application from source code. Hey, like it or not, Linux geeks love the cutting edge. Oh, sure, a few bearded sys admins out there beat their chests proudly proclaiming the virtues of old and stable apps, but they still yearn to compile from source and so in the same breath they mention that no distro ever compiles postfix or openSSL or openSSH correctly and so they compile it from source themselves. So you're GOING to compile from source code if you're a unix geek, so you may as well start brushing up on those magic three commands.


SSH is, I think, one of the top reasons people get into Linux; otherwise they're stuck admin'ing a couple of 50 computers and they are finding they are actually having to get up and walk to each computer to do one stupid task -- and then one day it dawns on them: with Linux, they can just ssh into the computer, perform the task, and be done. And from there they learn about shell scripting, and it's all over.


bash$ ssh -X klaatu@

will sign you in, securely, as klaatu to the computer located at

Having problems? I find one of the most common issues is not having SSH running on the target machine. So get up, walk over to, login manually, and run something like...

bash$ su -c '/etc/init.d/sshd start' 

and this will start the ssh daemon, so that it's ready and waiting for incoming connections.


I think of this as a variant of ssh; it's a COPY function with which you can securely cp a file from your local machine over to a remote machine...or you can grab a file from a remote machine and cp it over to your local one. It's pretty cool.

bash$ scp gort@ ./foobarGort.txt

would copy foobar.txt from gort's machine over to mine, and rename it foobarGort.txt


 bash$ scp foobarKlaatu.txt gort@ 

would copy foobarKlaatu.txt from my machine over to Gort's, as foobar.txt


This is one of my favourite apps because it's the one I use to make my backups. And I backup FREQUENTLY.

bash$ rsync -av /home/klaatu /media/backups/klaatuVault 

There is more you can use it for, but I tend to only use it for that simple command, simply because utilizing too many of its network capabilities makes me nervous due to that "r" in rsync as opposed to an "s".


This is a cool app to know about because it will encrypt stuff for you, nad give you a way to verify identity when emailing. I have it set up on all of my machines and email clients. I'd go into how to use it except that it's a little complex. I have a very good intro to it in the 2nd or 3rd season of The Bad Apples, and a lesson on how to integrate it into alpine on Hacker Public Radio.

....so that's all well and good but let's look at this logically:

In order to know the *nix command line, do you need to know commands? or do you need to know the shell, or do you need to know files? Well, actually, all three.

The shell, of course, is the thing that allows you to type something and have the computer do that thing; it is BASH, TSCH, CSH, ZSH, and others. In order to interact with the command line efficiently, you need to learn how the program works; some things you probably already know, like use the UP ARROW to re-enter the previous commands or use TAB to auto-complete words in a directory or echo $PATH to see your path, and so on. These are all pretty common BASH shortcuts. Should you, then, learn BASH? BASH is one of the more ubiquitous shells out there, so quite possibly you should brush up on BASH, or choose another shell to learn...but learn at least one of them.

I find that BASH or BASH-like shells are available on any *nix system I come across, including the ones that I do NOT have the power to modify. Those are the ones that matter because they're the ones you will, of course, be stuck using some time in a pinch and you'll be cursing yourself for not having learnt the "industry standard". So when I refer to an "industry standard", I don't mean "the best" or "the one to which we should all succumb", I just mean it's the one you're gonna run into when you are in a rush, in a pinch, need something to get done 5 MINUTES AGO, and cannot change.


The point: learn BASH for its industry standardness. Explore other shells if you want, for fun.

BASH Essentials

There are lots of books on this subject, and probably lots of sites; you'd do yourself a favour by checking one out. There should be a book on BASH at your local library because it's been around forever. Otherwise there's a book-length dissertation on the subject via "man bash"

UP-ARROW reviews previous commands; how many it will remember depends on your HISTSIZE setting.

TAB auto completes words in a directory

Control-Key commands are really important to know because some of them just speed things up for you, but also because sometimes you will find yourself at a keyboard that has no arrow keys, or a console that doesn't recognize the delete key, or whatever. If you know emacs-style navigation and such, you will have no trouble even so:

CONTROL-A moves you to the beginning of the line

CONTROL-E moves you to the end of the line

CONTROL-L clears the display (it's just like typing "clear" at the prompt)

CONTROL-R searches your HISTORY for a previous command (like doing a "history | grep foobar")

CONTROL-F moves your cursor forward

CONTROL-B moves your cursor backward

CONTROL-D deletes

CONTROL-W deletes the string before the cursor

CONTROL-K kuts a string

CONTROL-Y yanks the string from memory and pastes it where ever you want it pasted

<command>-& invokes a command and returns a BASH prompt to you. That is, if you want to run, say, mplayer, so you can have a bit of music while you do important BASH stuff, you can type

mplayer ~/music/clayHawkins_theFalls.ogg

and the album will play but your BASH prompt will be occupied by mplayer's progress report (giving you the current bitrate and how far along in the album you are, and stuff like that). So you can enter:

mplayer ~/music/clayHawkins_theFalls.ogg & 

and the album will start playing, but instead of seeing constant mplayer output, you will be returned to your normal BASH$ prompt. Nice, huh?

...and so on and so on. Bsically, go learn emacs and your BASH skillz will be accordingly wicked. Hate emacs because you overheard some people who seemed like they knew what they were talking about saying that they didn't like emacs? Well, they were wrong...but if you really hate emacs then learn vim and go get the Z-Shell (ZSH) and use that. But keep in mind that some day you will hack into some device running a busybox shell with an emulated keyboard with no arrow keys, a mis-configured delete key, and no Escape key, and you will want to get stuff done. Knowing the emacs key bindings and BASH functions will be VERY helpful.


This is the kind of thing you just kind develop a feel for after a while, but in a nutshell:


You must know the etc directory because it has a lot of system configuration files. The way your computer starts all the little apps it runs after you turn it on, the way your graphical environment starts and how it recognizes your peripherals...they are all in this directory. Learn all about /etc/ and you will understand why your computer is or is not doing the things you want it to do.


the hidden files in your home directory contain configuration files (and more) for your personal environment.


Contains the GRUB files to control which kernel you can choose from at boot time...unless you use LILO, in which case you will be interested in /etc/lilo (see? I told you /etc was important).

/sbin and /bin and /usr/bin and /usr/sbin

are all directorys full of applications that either root uses, or you use directly yourself.

--- and that's all I can think of to say on the subject. Long live the unix command line.


1 Comment

One essential I love is the GNU screen. The ability to keep a persistent environment through SSH sessions is awesome, as is the ability to switch between multiple bash sessions at the press of some keys. Add the configurable taskbar, and it almost feels like a ncurses-powered CLI desktop :P


Share this comment

Link to comment

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now