Some BASH Basics

Before we get ahead of ourselves, it would probably be a good idea to go over some BASH basics.

Let’s start at the beginning, OK? The Bourne Shell was born at AT&T’s Bell Laboratories a while back. It was birthed by Steve Bourne, hence the name. The Bourne Again Shell (bash) is a direct descendent of the Bourne Shell (sh). It’s very similar to the critter that Mr. Bourne brought to life back at Bell Labs.

There are different types of shells for different purposes. You can have a login shell, which is interactive; a non-login shell, which is also interactive; and a non-interactive shell, like the one used to execute a shell script.

The characteristics of these shells are usually determined by a file in the user’s /home directory called .bashrc. It’s sort of like a configuration file in that items place within it will be faithfully followed by the shell when it is initialized. We’ve seen this already when we were pimping our BASH prompt in a previous article here. I’m over-simplifying, of course. There are other files, be they root or user oriented, that also affect BASH’s behavior. However, we don’t need to go into that at the moment. For now we just want to get a bit more familiar with BASH.

Symbols are an important part of BASH scripting. Some commonly used ones are (, ), [, ], and $. You can see them in action in this snippet of a script:


initialize_Suits ()
Suits[0]=C #Clubs
Suits[1]=D #Diamonds
Suits[2]=H #Hearts
Suits[3]=S #Spades

initialize_Cards ()
Cards=(2 3 4 5 6 7 8 9 10 J Q K A)
# Alternate method of initializing an array.

Standard Input, Standard Output, Standard Error You may run across these terms while experimenting with and learning BASH. The first is usually provided by your keyboard; typing, in other words. The second is just the printed reply that BASH gives you in the command line. The third is the standard error notice that BASH will give you when it can’t find something or follow a command you’ve entered. Here’s an example of an error:

$ cat jimy_grades.txt

cat: jimy_grades.txt: No such file or directory

You list the contents of your working directory and find that you mis-spelled that file. It’s actually jimmy_grades.txt. This is why the cat command could not find it and BASH provided that standard error output for you. You can also redirect inputs and outputs in BASH using the | and < > symbols. We’ll see redirection in action a bit more later on when we write a few simple scripts to do stuff.

What is a shell script? Well, it’s a file that tells the shell (BASH, in our case) to do something. How does it do this? We “code” or write step-by-step commands and subcommands within the script, using variables and flow control, to make the shell follow these logical steps to achieve our goal.

You can write scripts to do just about anything on your systems. For example, you can write scripts that automate backup or updating chores, etc. You can write scripts to randomly change your desktop wallpaper. You can write scripts that do mulitple chores for you; some become quite multitasking in nature, with more than just a single result. Scripts can be very useful tools.

Writing code, or scripting, is like learning any other human language. It takes time and effort to learn… and lots of practice. You have to practice what you learn or you’ll lose it the same way folks lose their second languages if they don’t speak or read/write them regularly.

We made a simple script in yesterday’s lesson. We showed how Mary was able to write a small script at her workplace that simplified a chore that she had to perform often during the day. We’ll move ahead in the coming days to more complicated scripting, but nothing too complicated. The goal here is just to familiarize you with shell scripting, not to make you and expert. Only you can make you an expert.

More soon…


Note: As always, please remember to click on the embedded links within my articles for definitions to unusual words, historical background, or links to supplemental informative sites, etc.

Beginning Shell Scripting

OK, let’s continue on with our lessons about the Linux Shell and the command line.

Today, we’re going to learn how to write a script that you can run from the command line that will actually do stuff. It’s a very simple script, so don’t expect anything spectacular. I was wondering what I could use as an example script for this lesson when I remembered a question someone at asked the other day about how to tell which users are currently logged into a Linux system. Let’s make a little script to give us that information.

Let’s say that Mary wants to see who is logged in on the Linux system that she maintains for her company. She could easily do this with one simple command from the command line:

mary@workplace:~$ who

bill           pts/4       April 10 09:12

james       pts/5       April 10 09:30

marjory    pts/11     April 10 10:02

ken           pts/16     April 10 10:31

That was pretty easy, right? What if Mary wanted to check this periodically during the day? Well, she could write a small shell script with the proper permissions that she could execute any time she wanted from the command line or the terminal within her graphical user interface. Let’s find out how she might do that.

Mary would first open the vim editor with the file name that she plans to use for this script:

mary@workplace:~$ vim onsys

Vim would faithfully carry out the command and open up ready to edit file onsys. At which point, Mary would enter these lines to create her script:

# custom who script – mary – 10 Apr 11


echo “Users currently logged into the system:”


# end of script

Here’s what Mary actually did… she made a comment in the first line that begins with the character #, so that the shell knows to ignore that line. In the next line, she sets the command “date” so the script will output the date along with whatever else she requests it to do. In line 4, she uses the built-in echo command to tell the shell to display whatever is being asked for following the echo command. In this case, Mary wants the script to display Users currently logged into the system: when she runs it. The next command that Mary enters into this little script is the built-in who command. And lastly, is her notation that the script has ended.

Now, to make this script work, Mary needs to make it executable. In other words, she has to change the file’s permissions to allow herself (and other, if she wants) to execute (make it run) the script onsys. She will do that this way:

mary@workplace:~$ chmod +x onsys

If she now listed the permissions for this file, they would look like this:

mary@workplace:~$ ls -l onsys

-rwxr-xr-x 1 mary users 94 Apr 10 15:21 onsys

What this means is that everyone on the system can read and execute this script, but only mary can write to (change) it.

OK, so Mary wants to test her script now, so she just types in the script name at the command line (assuming the script is in her working directory):

mary@workplace:~$ onsys

Sun Apr 10 15:48:09 EDT 2011

Users currently logged into the system:

bill           pts/4       April 10 09:12

james       pts/5       April 10 09:30

marjory    pts/11     April 10 10:02

ken           pts/16     April 10 10:31

And so, there you have it. Mary wrote a simple script using shell built-in commands to perform a function that she does repetitively every day. That’s what scripts do. They perform tasks for us at our bidding. Of course, scripts can get much more complicated; so complicated in fact as to be considered applications in their own right. A script is just a series of encoded commands and variables designed to do something, which is basically what an application is also.

Start yourself a directory in your /home directory where you can create and play around with scripting and scripts. It can really be fun. You can “automate” a lot of every day stuff that you do on your computer using custom-made scripts. Yes, you can do it. It ain’t rocket science. It is similar to the technology used to program rockets, though.

Have FUN!