If so, this article is for you. It's really just to get you started.
This isn't really a technical guide. This is a list of practical tips that, looking back, I wish I had seen somewhere when I started to make myself use the CLI on a regular basis. Once you get used to the CLI, you start to use it a lot; on my Linux box, the only window I usually have open that isn't a terminal is Firefox. Everything else - with a few exceptions - can, in my opinion, be done effectively from the command line.
So here's my list of tips for the CLI beginner:
1. Make use of auto-completion
This is a small tip, but useful if you don't already know it. If you're using the bash shell, you can usually press [ Tab ] to do this. In other words, say I have a directory I want to cd (change directory) to:
- user@localhost:~$ ls
- Directory_1 Directory_2 Directory_3 Other_Directory
- user@localhost:~$ cd Directory_2
Instead of taking the extra few seconds to type in "Directory_2", you can simply start the word and press tab. In this case, suppose you type "Dire[ Tab ]". As soon as you press [ Tab ], the shell will complete the word "Directory_" for you. It won't, of course, put the number, because there's more than one choice. If you had typed "Oth[ Tab ]" or even just "O[ Tab ]", it would completely fill the word "Other_Directory" for you.
This same tip will work if you are starting to type an executable name in your $PATH (the variable that knows where to find all of your executable files). Suppose you wanted to run the program gnome-system-properties from the command line (which would actually launch a GUI, but can be useful anyway). To speed things up, type a few letters and hit [ Tab ]. Bash will complete the string as far as it can until there is any uncertainty, which probably means up to 'gnome-'. Perhaps you've forgotten the exact name of what you're trying to run? Hit [ Tab ] again and you'll be given a list of possible completions. Start typing again hit [ Tab ] to complete if you get lazy.
You will still, however, have to press [ Enter ].
This same tip will work if you are starting to type an executable name in your $PATH (the variable that knows where to find all of your executable files). Suppose you wanted to run the program gnome-system-properties from the command line (which would actually launch a GUI, but can be useful anyway). To speed things up, type a few letters and hit [ Tab ]. Bash will complete the string as far as it can until there is any uncertainty, which probably means up to 'gnome-'. Perhaps you've forgotten the exact name of what you're trying to run? Hit [ Tab ] again and you'll be given a list of possible completions. Start typing again hit [ Tab ] to complete if you get lazy.
You will still, however, have to press [ Enter ].
P.S. - If this isn't working, you might not be using the bash shell (type set | grep SHELL or something reasonably equivalent to find out what you're using). This doesn't mean all hope is lost. If you're just in plain old sh, for example, you can use the wildcard character '*' to complete your phrase. In the first example above, then, you could type 'cd Dire*2' to go to Directory_2.
2. Understand I/O Redirection
As many people will tell you, piping and I/O redirection is perhaps the most powerful part of the nature of the CLI. Take this example:
Suppose you had to build a toy car. You need someone to carve the right shape, someone to put on the wheels, someone to screw everything in, and someone to put it in the correct package. In one case, you could give the car to the person who carves it, and then take it back. You would put the car in a box and go find the person to put on the wheels. When they were done, you would package it and take it to the person adding the screws. Finally, you would put it back in a package and take it to the person who puts it in the package for marketing.
In another example, though, you could setup an assembly line and use a conveyor belt. This removes your role as the messenger and removes the intermediate packaging. This second example is analogous to the CLI. Whereas in the GUI example one has to use a program, save the result, and then open a whole new program, the CLI-master can simply tell each program in line to pass on their result to the next program. You might write, for example:
2. Understand I/O Redirection
As many people will tell you, piping and I/O redirection is perhaps the most powerful part of the nature of the CLI. Take this example:
Suppose you had to build a toy car. You need someone to carve the right shape, someone to put on the wheels, someone to screw everything in, and someone to put it in the correct package. In one case, you could give the car to the person who carves it, and then take it back. You would put the car in a box and go find the person to put on the wheels. When they were done, you would package it and take it to the person adding the screws. Finally, you would put it back in a package and take it to the person who puts it in the package for marketing.
In another example, though, you could setup an assembly line and use a conveyor belt. This removes your role as the messenger and removes the intermediate packaging. This second example is analogous to the CLI. Whereas in the GUI example one has to use a program, save the result, and then open a whole new program, the CLI-master can simply tell each program in line to pass on their result to the next program. You might write, for example:
- user@localhost:~$ carver | wheeler | carpenter > correctBox
Here, the carver program sends it's output to the wheeler program which sends it to the carpenter program which then writes all of its output to the file correctBox.
As a more useful example, consider this command in my .bashrc file:
As a more useful example, consider this command in my .bashrc file:
- alias dl = 'ls -laht | sed -n /^d/p'
After the next two tips, you'll understand what that does.
3. Use Stream Editors
More specifically, I mean that you should try to understand the power of commands like sed and grep. Programs like these can help you get the data you want from other commands. Say, for example, that I wanted to find all of the C source files in my ~/Code directory. I might write something like:
3. Use Stream Editors
More specifically, I mean that you should try to understand the power of commands like sed and grep. Programs like these can help you get the data you want from other commands. Say, for example, that I wanted to find all of the C source files in my ~/Code directory. I might write something like:
- user@localhost:~$ ls Code | grep '\.c'
First of all, do you understand why simply grep .c doesn't give the same results in general? If not, we'll get to that in a second. Right now just realize that the period is a special symbol (a metacharacter).
The above command does this: first, it uses the ls command to print out all of the regular files and folders in the directory. The grep command then receives these filenames (just the names, not actually the files) as they are generated, and it selectively decides which ones to output. In this case, it only prints out the strings which contain the substring '.c', which is more-likely-than-not a C source file. Of course, if you happen to have a file called "a.b.c.d.e.txt", it will catch this as well.
For dealing with more advanced structured, we can use sed (among other tools); that, however, is a topic beyond the scope of this article. As a basic primer, it can be said that sed usually operates on text using regular expressions, a powerful tool that the Perl hacker may already be familiar with. This is what it does in the above example; for everything output by ls -laht (which, by the way, is a listing of the current directory in Long form with All files listed (as opposed to only non-hidden ones) in Human-readable file sizes, sorted by Time modified), sed only lets through lines that start with the letter 'd', which, using ls's long form, means that they are directories. That's why I called this alias dl - it stands for directory listing (in my head, at least).
It should be noted that this is only a basic usage of sed, and in fact this exact same thing can be done with grep (ls -laht | grep ^d). That '^' in both the sed and grep expressions is called a metacharacter. Just like the period that we were searching for in the first grep example above, we would have to backslash-escape the character like this if we actually wanted to search for the character '^':
The above command does this: first, it uses the ls command to print out all of the regular files and folders in the directory. The grep command then receives these filenames (just the names, not actually the files) as they are generated, and it selectively decides which ones to output. In this case, it only prints out the strings which contain the substring '.c', which is more-likely-than-not a C source file. Of course, if you happen to have a file called "a.b.c.d.e.txt", it will catch this as well.
For dealing with more advanced structured, we can use sed (among other tools); that, however, is a topic beyond the scope of this article. As a basic primer, it can be said that sed usually operates on text using regular expressions, a powerful tool that the Perl hacker may already be familiar with. This is what it does in the above example; for everything output by ls -laht (which, by the way, is a listing of the current directory in Long form with All files listed (as opposed to only non-hidden ones) in Human-readable file sizes, sorted by Time modified), sed only lets through lines that start with the letter 'd', which, using ls's long form, means that they are directories. That's why I called this alias dl - it stands for directory listing (in my head, at least).
It should be noted that this is only a basic usage of sed, and in fact this exact same thing can be done with grep (ls -laht | grep ^d). That '^' in both the sed and grep expressions is called a metacharacter. Just like the period that we were searching for in the first grep example above, we would have to backslash-escape the character like this if we actually wanted to search for the character '^':
- user@localhost:~$ ls -laht | sed -n /\^d/p
In this case, '^' would no longer mean 'beginning of line'; instead, it tries to find the caret symbol within the inputted text.
4. Force yourself to use the CLI by trying to do everything with it until it gets to the point where you know where you want to be.
This is an interesting point that other people might not suggest, but I did this and it seemed to work. If you really do have a desire to use the CLI but don't know how, just try forcing yourself to use it. I did this by installing Fluxbox as my desktop environment and making the only two things in my menu 'firefox' and 'gnome-terminal'. I use Alpine for my mail, VIM as my editor, Irssi as my IRC client, CenterIM as for Google Talk, and then I usually have one or two other terminals open just for kicks. One probably has Nethack open. The only non-terminal based program I use in Linux is Firefox, because the the Web really has evolved beyond the reasonably capacity of, say, Lynx (some might argue that point). I also use VLC occasionally to watch movies, which obviously can't be done in the CLI. I used to even use the CLI for playing music, but since my music started being centralized on my Mac, I usually just plug my speakers into my iPod.
So I suggest you do something similar - just keep Googling things like "best CLI programs" or "favorite terminal applications" until you know a reasonable amount about what's out there (and what's good) for the command line. Make yourself use them for a month and see how you feel. I decided not to go back (although I can't say that very well now that I have a Macbook, but it was true for a long time up until a few months ago).
Best of luck!
5. Links & Resources
Bash Beginner's Guide
Advanced Bash Scripting
Linux Shell Scripting Tutorial
CLI Apps
Favorite Command Line Programs
4. Force yourself to use the CLI by trying to do everything with it until it gets to the point where you know where you want to be.
This is an interesting point that other people might not suggest, but I did this and it seemed to work. If you really do have a desire to use the CLI but don't know how, just try forcing yourself to use it. I did this by installing Fluxbox as my desktop environment and making the only two things in my menu 'firefox' and 'gnome-terminal'. I use Alpine for my mail, VIM as my editor, Irssi as my IRC client, CenterIM as for Google Talk, and then I usually have one or two other terminals open just for kicks. One probably has Nethack open. The only non-terminal based program I use in Linux is Firefox, because the the Web really has evolved beyond the reasonably capacity of, say, Lynx (some might argue that point). I also use VLC occasionally to watch movies, which obviously can't be done in the CLI. I used to even use the CLI for playing music, but since my music started being centralized on my Mac, I usually just plug my speakers into my iPod.
So I suggest you do something similar - just keep Googling things like "best CLI programs" or "favorite terminal applications" until you know a reasonable amount about what's out there (and what's good) for the command line. Make yourself use them for a month and see how you feel. I decided not to go back (although I can't say that very well now that I have a Macbook, but it was true for a long time up until a few months ago).
Best of luck!
5. Links & Resources
Bash Beginner's Guide
Advanced Bash Scripting
Linux Shell Scripting Tutorial
CLI Apps
Favorite Command Line Programs
Posts
