Skip to main content
LPI Linux Essentials

3.3 Turning Commands into Scripts

By August 16, 2013September 12th, 2022No Comments

Turning Commands into Scripts

If we can type commands at the command line then we can string those commands together into shell scripts. In this way, we can quickly carry out repetitive tasks effectively. A shell script is a text file with a bunch of commands and operators; so first we have to look at the text editors available to us at the command line.

First we take a quick tour of vi, pico, nano and joe. These are all command line editors in Linux, if you are using the GUI then you may use editors like kate or gedit. The emphasis of the LPI training is at the command line and the CLI is always available to you and often quicker.

Vi or Vi Improved (vim) is one of the classical editor in Linux and Unix. It may be difficult to use at first; however is very powerful and quick to use once mastered. I am sure most people only use a little of its functionality but that can be said of all editors really. Most Linux distributions will ship with this editor and knowing the basics is going to be useful.

The first video linked here looks at the basics a vi / vim

The second video linked here looks at some of the more advanced feature of vi and how we can add indents into a script

Pico, nano and joe are all again command line editors but have a basic menu system. This helps when you are starting but also can slow the process down and certainly do not have the features available in vi.

The video linked here looks at using nano on CentOS

We can then build our first script and instead of Hello World we can print the Process ID or PID that the script runs in using the variable $$.

We will learn that scripts will normally start with the shebang, identifying the command line shell to use when executing. This is a commented line, starting with a hash #, but is read when the script runs.

#!/bin/bash #!/bin/sh #!/bin/ksh

The above lines could be used as the shebang. The first being Bash , then the Bourne Shell and the final would be if we wanted to run the script in the Korn shell. Only one would be used per script and, if used, must be the first line.

Certain system variables exists for us to use. $$ represents the PID of the script, for long running scripts this may be useful to write out to a file so if we need to send a signal to end the script we know the process to send the signal to.


From the above graphic we can see the output from the command line, within a script we may use something line this:

#!/bin/bash echo $$ > /var/run/script.pid

The file then would contain the process id of the script. This would only be useful if the script were to be long lived. Other variables we may use

  • $0 : The script name
  • $1 : The first argument passed to the script
  • $# : The number of arguments passed to the script
  • $* : The list of arguments passed to the script

We can build up the script so that we can process files passed as arguments to the script.

#!/bin/bash
COUNT=$(wc -l $1)
echo $COUNT

If we ran the script like this

scriptname.sh /etc/hosts

We would count the number of lines in the hosts file and print the count out to the screen. This identifies and issue that we may have; what if the user input just /etc rather than a regular file. This is where we could add in IF statements:

#!/bin/bash
if [ -f $1]
 then 
 COUNT=$(wc -l $1)
 else
 echo “$1 is not a file”
 exit 53
fi
echo $COUNT

The script tests that the supplied argument is a regular file. If it is we can run the word count if it is not we echo out a warning and exit the script with an error code. This introduces the basics of shell scripting and the video follows to give you a demonstration: