The following is an overview of the concepts and basic mechanics of the Bash command-line interpreter, i.e. shell program with which we use to send commands to our computers.
Bash is the command-line interpreter that serves as the interface between us, the user, and the computer's operating system, e.g. OS X Yosemite on your laptop, or Ubuntu 14.04 for corn.stanford.edu. Bash is designed to read characters that we input – such as by typing mkdir some_new_directory
in via Terminal – and then passing them to the operating system to execute.
If we wanted to create three new directories on our computer system named apples
, oranges
, and pears
, we, the user, don't directly tell the operating system, "Make me three new directories named apples
, oranges
, and pears
". We type in that command via text, in a format and syntax understandable by Bash, which then translates that text into a command the operating system can understand.
For example, in Bash, to create those three new directories, we type the text sequence of:
mkdir apples oranges pears
And then we hit Enter, which tells Bash to now read that line of text input and then interpret it as a command (or series of commands) for the operating system to execute.
Based on its syntax rules, Bash reads that line of text, mkdir apples oranges pears
, and interprets mkdir
as a command (or program), and the next three words, apples
, oranges
, and pears
, as the names of the directories to create.
The translated commands are sent to the operating system which then executes the commands, creating those three new directories. Below is an animated GIF of me making those three directories on my own Mac OS X laptop:
On the top half of that GIF is the graphical user interface (or GUI) for the OS X operating system, i.e. what you're used to seeing when you use your Mac laptop. The bottom half is me accessing Bash via the OS X's Terminal app, letting me control my operating system via the Bash shell.
As you can see, the shell reads my command and executes them, and the result affects the underlying operating system, as if I created those directories via the graphical user interface by pointing and clicking.
The Software Carpentry project has a more detailed description of Bash and the purpose of a shell:
A shell is a program like any other. What's special about it is that its job is to run other programs rather than to do calculations itself. The most popular Unix shell is Bash, the Bourne Again SHell (so-called because it's derived from a shell written by Stephen Bourne—this is what passes for wit among programmers). Bash is the default shell on most modern implementations of Unix, and in most packages that provide Unix-like tools for Windows.
Note: If you are a pre-2014 Stanford enrollee and were running into problems following my examples on corn.stanford.edu, that was because you were on a different shell, tcsh, which has its own syntax for interpreting commands. That is why typing in bash
, to start up the Bash shell, fixed those problems.
Our initial usage of the Bash program will be to login and use it interactively: that is, it prompts us, we type in a command, Bash evaluates that command, prints the result, and then prompts the user for the next command.
This loop of interaction continues until the user logs out (or the system crashes).
Think of the prompt as the way that Bash tells you, Hey, I'm waiting for you to tell me what to do.
When logging into the corn.stanford.edu system bash, the default prompt should look like this:
your_sunet_id@corn30:~$
Which translates to:
Your Stanford ID
@
The current computer:
Your current directory$
In the screenshot below:
Here's what's going on
dun
corn20
/tmp/x
echo 'Hello bash!'
Hello bash!
The prompt can be customized to show what you want (including emoji, or what have you), but the key concept is that everything to the right of it is your space to issue commands.
Note: For the purposes of this guide, I'll often use the generic prompt user@host:~$
, whereas the prompt for the GIF screencasts will look different. All you have to do is just know what a prompt generally looks like. In the examples, you shouldn't need to focus on what each prompt looks like, as I'll likely be inconsistent.