A growing number of Linux users these days are going into the OS with little knowledge of some of the shell commands that make life much easier. While most modern gui-based systems have GUI-fyed applications to handle most of the things you can do in the shell, but being familiar with a
That said, let's get to some of the common and useful commands for the Borne Again (Bash) shell.
(as an aside, the reason I'm writing this for the Bash shell is because...I use the Bash shell.)
The Most Important Command
man is the manual command for Bash, typing man command-name gives a description of the use of the given command. It really is the most important command to know when learning how to do things via the shell, and since I suck at remembering flags, it is a command I use numerous times in any given day.
ls lists all of the files in the directory you are currently in. Simply issuing ls will display the contents of the directory in a space-delimited list form. You can use "flags" (in essence, arguments prefixed with a hyphen (-)) to get some more information. Four common flags I use on a daily basis are as follows:
-l : List output - formats the output into a nice list format that displays the owner of the file, the date last modified, as well as some other useful data. (such as file permissions; more on that when we get to chmod)
-a : All. By default, ls will not display files that begin with a period, such as the .config file in your home folder.
-s : Size. Shows file size as well as listing the files
-t : Time. Orders the list by the last-modified time, from earliest to latest. (by default, the list is ordered in lexicographical order.)
And you can combine flags, the most common usage of ls I personally using being ls -last, a combination of the above flags.
Here is an example of what these various ls commands might look like:
cd is the change directory command, it will change the directory the shell is in. You can use absolute paths here such as cd /home/user or use a relative path, ie. cd documents (if you are in a directory with a documents directory in it)
Two symbols of note that can be useful for the cd command are ~ and .. ~ signifies your home folder, so typing cd ~ will go to your home directory. (actually, just typing cd with no argument will bring you to your home directory as well). .. signifies the parent directory of the one you are currently in. For example, if I were to type cd .. in my home directory, I would move from /home/user to /home.
cp copies files. The first argument is the file to be copied, and the second argument is the output file.
mv "moves" files. It is also how you rename files via the shell (you move the file to a new file)
rm removes files. Be careful about what you remove, as unless you use the -i flag, the files will be removed without prompting you.
cat concatenates the contents of the file (or files) it takes as arguments and displays them on the screen. It's as simple as that, here is an example output:
touch "touches" a file, modifying it's timestamp. Therefore, if you touch an existing file, you change it's timestamp, however if you touch a file that doesn't exist, touch will create the file. It will be completly empty, however.
Top provides a constantly-updating (you press q to exit it) "system status", which lists the top processes in terms of hardware usage, and more importantly for the next command, it gives process IDs for the processes.
An example of what it may look like:
kill sends signals to the process you specify. These signals take the form of numeric flags, so an example of a kill command would be kill -9 2848.
There are a lot of signals, but from personal experience, I only use three, -1, -2, and -9
-1 is HUP, the hangup signal. This is this is the signal that is sent to any running processes when you close the shell (using kill -1 doesn't close the shell, however).
-2 is INT, the keyboard interrupt. It is the equivalent of pressing Ctrl+C with a program running in the shell (but you can do it to programs running in the background as well)
- 9 is KILL, the sure kill. You kill the process. Period. Only zombie processes cannot be killed by -9. (zombie processes are beyond the scope of this writing)
Here is an example:
In terms of general use things you'd use on an average day, that's all I've got for the basic stuff, let's move on to some more intermediate things.
The concept of a pipe, at least in terms of the shell, is to use the output of one command as the input for the next one, for instance the following line:
cat /etc/passwd | less
Will cat the file /etc/passwd (it stores information about the various 'users' of the machine) and then use the output of that command as the input of the less command (less is a command that makes large files easier to read by allowing you to scroll up and down in them)
That's really all there is to pipes, at least in terms of what you would do with them on a daily basis.
An important topic of basic shell use is redirection. The >, >>, and < symbols are the key redirection symbols you'll be using most of the time. > and >> are output redirection, they redirect the standard output location of a command (generally the monitor) to a file. For example, the following command directs the results of the echo command (which "echos" its arguments back to you), and instead places the output you would normally get on the screen into a file:
The difference between > and >> is that > is overwrite and >> is append. Using > will overwrite the output file if it exists, where >> will append to the end existing files.
< is input redirection, generally I don't use this as much as I do output redirection, but it's there, and its functions similarly to output redirection.
In the Bash shell, aside from redirecting standard input (usually the keyboard) and standard output (usually the monitor), you can also redirect where error messages go using the 2> notation in the line. (as for an explanation of the 2, standard input, output, and error can be referenced by numbers when using redirection, 0, 1, and 2 respectively. Technically speaking, you can notate standard output as 1> instead of >, but that is redundant.)
Look at this example:
The first time I use the bad command without any redirection, and the error is displayed on the standard error device (the monitor). However, the second time I do it, I redirect the error output to a file instead of the standard error output. This is useful for creating error logs.
If you wish to just suppress error messages, you can direct the error out to the /dev/null file. The null fill is...null. If you direct output or error to it, they are "suppressed"; they don't display on the standard output/error and they aren't written anywhere. If you direct input from /dev/null, you get...well, null, nothing. Not as useful for everyday things as output/error redirects, but it still has it's uses.
And that's all I can think of off of the top of my head for commands I use on a daily basis, hope it helps.