Have you ever wanted to learn “scripting” in linux? Making them is easier than you might think. Sometimes scripts (often referred to as shell or bash scripts) are real programs with complicated code inside. Other times they’re just a long list of tasks that users put together to make getting things done under Linux faster and easier.
In this article we’ve decided to make a quick guide explaining how to make a basic shell script under Linux. This tutorial won’t turn you into a Bash or scripting expert. Instead, it will show you how easy it is to get started (and the best practices) scripting in Linux.
Why would you make a script?Making scripts in Linux is a very useful skill to have. Even if you don’t fully understand Bash, you can use your limited knowledge of the terminal to automate and “mass-accomplish” some tasks, or simply to open multiple applications simultaneously .
For example: maybe you just built Arch Linux from scratch. The operating system isinstalled, along with all of the basic packages, and it can boot to the terminal when the operating system starts up. Arch Linux takes time to set up, so the process isn’t completed.

It is at this point where the user could write a Bash script and accomplish everything at once. None of this is programming, or advanced for that matter. However, given the fact that the user understands enough about the way Arch Linux works, they’d be able to automate almost the entire post-setup process (desktop environment, drivers, user setup, etc.).
The only limit to your bash script is your own Linux and Bash knowledge! Making them is easier than you might think.
Getting started ShebangsWhen writing code, things need to be specified and resources loaded. When scripting with the shell, some things need to be specified as well. In bash scripting this is known as a “shebang.” The shebangs used in scripts tells the script what interpreter it should execute under. This could be Bash or any other scripts available in your system. Do note that different languages have their own shebangs.
For example: When writing a python script, the shebang would be #!/usr/bin/python , etc.
Bash has many different shebangs that can be used, but most users have probably only seen the #!/bin/bash one. As a general rule, use #!/bin/bash whenwriting a simple script and don’t plan on taking it off of Linux. All modern Linux distributions are on the same version of bash, and the bash shell is usually located in the same place.
Another shebang that proves itself useful is the #!/usr/bin/env bash shebang. This one is designed for portability and should be used if the script is designed to run on other Unix-like operating systems (BSDs, macOS, etc.).
Best PracticesWriting scripts in Bash can be a complicated process if the writer makes it that way. More often than not, scripts are just a collection of different operations. Moving a file, downloading something, installing programs, and that sort of thing.
Keep in mind that Bash is a language that is designed to manipulate files and processes on the system. If Bash meets your needs, that is good. However, do understand that for advanced programming, Bash really isn’t the right choice, and it’d be best to move onto something like Python. Make your scripts “SH” compatible and in the “.sh” format if the plan is to use scripts on more than just a Linux platform. Though other UNIX-like operating systems may have “bash-like” shells, some don’t have bash at all, and it’s good to be prepared for this. Learn the Bash shell and how it works. It’ll help you write your scripts better. Always use a shebang and more importantly: use the right one . It can mean the difference between a good script and a terrible one that doesn’t work right. Always comment out every operation. In six months you might come back to your script and wonder what everything means, so it is crucial that your script is documented well and easy to understand (for you and anyone else who might see it). Make your code readable. Even if your script isn’t anything complex, it should still make sense, and making them is easier than you might think. Test your script for errors before giving it out to others. Don’t make others bug test for you. Ideally, scripts should work before you send them out for people to use. Making a scriptTo start scripting, all you need is a text editor. Any simple text editor will do it doesn’t have to be a complicated or comprehensive one. For this example we’ll make a simple Ubuntu update script using Gedit.
#!/bin/bashThis first part of the script is the shebang, like mentioned before. This allows the script to tell the interpreter what it should use to understand the code.
Next, let’s write a comment. This will allow anyone who uses the script to understand what the code is meant to do. Comments can be added to a script by placing a “#” symbol. Anything after it won’t be picked up by the script.
# My Simple Ubuntu Update ScriptNow it is time to add the code to the script. In this case we’re working on making a bash script that will run Ubuntu’s two update commands in succession. Start off with the update software sources command.
sudo apt updateThe second part of the script is the apt upgrade command. This command allows the previously checked updates to be installed. Add a -y to the end so that the script won’t need any user interaction. This will allow the command to update by itself.
sudo apt upgrade -y
Save the script with a “.sh” extension. For example, “myscript.sh.”
To run the script, open a terminal and type:
sudo chmod +x myscript.shThis will mark the newly created script as executable. Doing this to scripts isn’t always required, as for the most part Bash will run it anyways. Regardless, this a good practice when scripting.
To execute the newly created script, run the following command:
sudo bash myscript.sh.
File Extensions
There isn’t a difference in file extensions for scripts. Naming a file with the “.sh” file extension does little to affect the way the “program” runs. A Bash script will still run with no file extension blank text files and everything in between as long as the right commands and arguments are present.
Even though the Bash shell ignores file extensions, that doesn’t mean the script writer should. Some desktop environments that allow for setting shell scripts to run at startup depend on the script to have the correct “.sh” file extension. This also helps for organization purposes, too.
When it comes down to it, most shell scripts are saved as “.sh” files for portability. The “sh” doesn’t have anything to do with Bash itself, and the script can run with any compatible shell.
Alternatively, scripts can be saved as .bash, .ksh (Unix korn shell), etc. These file extensions are inferior and really limit the usefulness of a script. This is due to the fact that they are designed only for the shells that use those extensions.
Code resources
F