Take control of the command line
Ease into your comfort zone with these tips for customizing Bash.
One way to reduce the anxiety of using the command line is to gain as much control over the situation as possible. Bash, the default shell in most GNU/Linux distributions, is no exception. If you know how to customize Bash, you should start to lose the sense of trauma (no doubt induced by an exposure to DOS early in your computing life) that seizes you when the idea of using a command line is raised.
Of course, many customizations are interesting only if you are a developer. Frankly, listing every possible option would require a column five or six times the length of this one. Still, the examples below can be interesting to users at any level and give some sense of the possibilities. They range from creating short names for commands and changing default permissions to customizing the look and feel of the command prompt and the behavior of the Bash history.
The Files Involved
Before you begin, you should know that all user accounts have potentially four files associated with Bash. All are ordinarily hidden, but you can see which ones are used by your distribution by typing ls -a .bash*.
Two Bash files are of limited interest if you are learning how to customize. The .bash_history file is a list of previously entered commands, one per line. Although you can edit it in a text editor, most people use the Up and Down arrow keys to scroll through the history for a command they want to reuse. The optional .bash_logout file lets you run a script when Bash exits, but it is often unused.
The other two Bash files are central for configuration. The first, the .bashrc file, contains basic settings for the history and prompt options and is always present. It is automatically re-created by the /etc/bash.bashrc file if deleted. The second is .bash_profile, which includes additional options and configurations. If .bash_profile is not present, the user account uses /etc/profile instead – the default for the entire system.
These files can be edited directly or with the use of a command like export.
Changing the Path
The path is a list of directories the operating system looks to for commands that you enter. It consists of all the paths defined in /etc/profile plus any added to .bash_profile in your home directory. Should a command not be in the path, you either have to enter a complete path when you type the command or change to the directory in which it is found – neither of which is as convenient as simply entering the command and trusting Bash to know where to look for it.
To add a directory to the path, you can open your .bash_profile in a text editor and search for the $PATH statement. If it isn't mentioned anywhere in the file, you can enter the lines manually at the end of the file. For instance, if I wanted to add a /bin directory for executables to my home directory, I would add:
PATH=$PATH:/home/bruce/bin export PATH
Alternatively, I could modify the path from the command line by first declaring the path, then setting it:
PATH=$PATH:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/bruce/bin export PATH
If you ever decide that you do not need a directory in your path, you can re-define it with the same two lines, simply omitting the unneeded directory.
Short Names or Aliases
Commands can become long and involved. Depending on the command, you can have the basic command, any number of variables, a source file or directory, and a target. In some cases, as with the apt-get command, you can also have a sub-command in addition to the basic one. This structure can be hard to remember, and, to make matters worse, one mistake in syntax can have unexpected results or invalidate the command.
Thus, Bash allows you to define and use shortcuts. You could create these shortcuts by editing .bashrc in a text editor, but it is faster to use the built-in commands alias and unalias. As you might expect from the names, alias creates shortcuts, and unalias deletes them.
The structure of these commands is simple. For example, if you always wanted to see color-coded lists of directory contents, you might enter the command alias ls ='ls --color=auto'.
Technically, you should begin with alias -p, but the -p option, which sends the results to standard output, is unnecessary in all the distributions I've tried, so you don't need to bother with it.
Once you have defined this alias, instead of always entering ls --color=auto, all you have to do is type ls. This savings of keystrokes can quickly add up if you use the command line for file management. You can do the same for any Bash command or application, including one for the desktop, if you choose. The obvious limitation is to choose a shortcut that you are unlikely to enter by accident, although I suppose you might also find – at least in theory – that an alias creates a conflict between incompatible options.
To delete a shortcut is even simpler: Type unalias, followed by the name of the shortcut. For instance, if you decide that color-coding a directory listing isn't something you prefer after all (possibly because you are color blind, or you prefer the -F option to indicate file types by a character at the end of the name), then you would enter unalias ls.
This command would delete the alias, but not, let me stress, the command ls itself. If you want to delete all aliases, the command is simpler still: unalias -a.
To see a list of defined shortcuts, type alias. If you use many aliases, you might add comment lines (#) in .bashrc, arrange your shortcuts by function, then view them in a text editor when you need a reminder. One sample .bashrc file I've seen had separate categories for programming, desktop applications, scripts, and half a dozen other purposes. Another included common typos, so that the user would not receive an error by typing yum intsall instead of yum install when adding packages to his Fedora system. As these examples show, how useful you find aliases depends entirely on your patience and ingenuity.
Buy this article as PDF
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.