As you know by now, Linux commands are extremely powerful. A single well crafted line can replace several minutes worth of GUI interactions. But just like the GUI, you’ll often find yourselves doing things over and over again. For example, I’d written earlier about implementing password change policies. In that, if we wanted to force users to change their password for the first time when the log in, we had to “expire” the password using something like “passwd -e [username]” immediately after creating the user.

What we’d like to have instead is a single command to bind multiple commands together. We should be able to take in parameters or variables, and manipulate them as we choose. These are called “scripts” in Linux, and they’re similar in concept to batch files in Windows. But with a lot more power. In this tutorial, we’ll take a look at the following:

  1. Creating a basic script;
  2. Setting permissions;
  3. Changing the PATH variable.

Creating a Basic Script

A script is a text file like any other. In this, I create a new script by using the “vi” text editor command:

vi testscript

And here’s what I put into it:

#!/bin/bash
# I'm just going to output a simple message here
echo "This is the simple message!"

The first thing to notice is that the file starts with the following line:

#!/bin/bash

This tells Linux that the file is a script. It should be the very first thing in the file. After that, you can leave comments throughout by starting new lines with a “#” character, as you can see in the second line.

Other than that, each line is a new command. In this simple example, I merely echo a statement. Save this file and exit your text editor.

Changing Permissions to Enable the Script to Run

If we try and run the script immediately after creation, we get an error message that permission has been denied:

To rectify this, we need to allow it to be executed. We assign permissions 755 or 700. The former is for everyone to have the right to run the script. The latter grants only you permission. Type the following to change the permission:

chmod 755 testscript

Now when we try and execute the script in its own directory, we get the following output:

It works! Now we come to the last part about setting paths.

Configuring the PATH Variable

Notice how we can’t just write the name of the script and run it as a command. We need to specify the entire path. If the script is in the current directory, we have to append “./” to the script name as a substitute for the current folder. We can solve this by adding the current directory to the PATH folder by typing this:

PATH=".:$PATH"

Running this now allows us to use the script as if it were a command as long as it’s in the same directory as ours:

Unfortunately, this is only a temporary solution. The change will be lost when you reboot as seen here:

To make this permanent, we can modify the following file in CentOS/RHEL:

~/.bash_profile

In this, the PATH variable for the current user is defined. In my example, I change the following line:

PATH=$PATH:$HOME/.local/bin:$HOME/bin

to this:

PATH=$PATH:.:$HOME/.local/bin:$HOME/bin

The change is very subtle. It’s highlighted in red below:

This adds the current directory to our PATH variable permanently. Now when you reboot the server, the changes to the PATH variable are made permanent as shown here after a reboot:

Linux scripts working after reboot!

Now the current directory is added permanently to your PATH variable.

Creating a “bin” Folder:

Another option would be to move your scripts to a directory that already exists in the PATH. For example, in the above directory you can see that the following location is referenced in PATH:

$HOME/bin

You can get the location of a system variable like $HOME by typing in the following:

echo $HOME

In my example, $HOME refers to /root. So I create a new directory in /root called “bin” and place my script files inside it. Since $HOME/bin is already added to the PATH variable by default, I can run my scripts without having to mess around with the PATH at all! It’s generally accepted as a more convenient solution.

So these are the basics of how to create a skeleton script, change the permissions, and set the paths. In the next tutorial, we’ll look at some actual examples of scripts you can use to automate some of the more routine tasks like creating users and setting password policies using just a single command.

tracking pixel

Is your website slow?

Enter its URL below to find out now:

About the Author

Bhagwad Park

Leave a Reply

Your email address will not be published. Required fields are marked *