📖 What is a BASH File?
A BASH file is a shell script, a plain-text file holding a list of commands that the Bash shell runs one after another. It is how people automate work on Linux and Unix systems, turning a series of terminal commands you would otherwise type by hand into a single file you can run whenever you like.
Bash stands for Bourne Again SHell, the command interpreter built into most Linux systems. When you run a BASH file, Bash works down the file line by line, performing each command in the order it appears, exactly as if you had typed them at the prompt. That makes these files ideal for repetitive jobs such as backing up folders, installing software or setting up a computer the same way every time.
The file usually carries a .bash or .sh extension, though on Unix it often has no extension at all, since the system decides how to run it from a special first line rather than from the name. Whatever it is called, the content is ordinary text, so you can open and read a BASH file in any editor to see precisely what it will do before running it.
Key Characteristics
- A list of commands run by the Bash shell
- Plain text you can read in any editor
- Automates tasks on Linux and Unix
- Run from a terminal, not double-clicked
Good to Know
- Bash means Bourne Again SHell
- Often has no extension on Unix systems
- Needs execute permission to run directly
- Not native to Windows without extra tools
⚡ Quick Facts
| File Extension | .bash or .sh |
| What It Is | A shell script for the Bash shell |
| Bash Stands For | Bourne Again SHell |
| Created By | Brian Fox, in 1989 |
| Runs On | Linux, Unix and macOS |
| Run With | bash script.sh or ./script.sh |
| First Line | The shebang, #!/bin/bash |
| File Type | Plain text |
⚡ The Shebang Line
Most BASH files begin with an unusual first line that looks like a comment but does a special job. It is called the shebang, and understanding it clears up much of how these files work.
The shebang starts with the two characters #!, spoken as hash-bang, followed by the path to an interpreter, so a Bash script typically opens with #!/bin/bash. When you run the file, the system reads this line first and uses it to decide which program should carry out the commands, in this case Bash itself. Without a shebang, the file runs under whatever shell happens to be active, which can behave differently from one computer to the next. A common portable alternative is #!/usr/bin/env bash, which looks for Bash wherever it is installed rather than assuming a fixed location. Because the system reads this line to choose the interpreter, a BASH file often needs no extension at all, since the shebang, not the file name, decides how it runs.
#!/bin/bash tells the system to run the file with Bash. It is why a script behaves the same way everywhere and why the file name matters less than that first line.
🗂️ What a BASH File Holds
Inside a BASH file is ordinary text arranged as instructions for the shell. Beyond a plain list of commands, a script can make decisions and repeat work, which is what makes it more than a simple recording.
Commands
The same instructions you would type at a terminal, listed in the order to run.
Variables and Input
Named values and answers from the person running it, so the script can adapt.
Loops and Conditions
Ways to repeat steps or choose between them, so the script reacts to what it finds.
Lines beginning with a hash are comments, ignored by Bash but useful for explaining what the script does. Everything else is run in sequence, and the shell's ability to loop over items, test conditions and store values in variables lets a short file handle jobs that would take many manual steps. This is why shell scripts are a everyday tool for system administrators and developers alike.
🔬 Inside the Code
The example below lays out the shape of a BASH file. Its shebang leads, and comments and commands follow just as you would type them.
A small Bash script that greets you
#!/bin/bash # greet the person running the script echo "What is your name?" read name echo "Hello, $name" # list the files here ls -l
The first line is the shebang, choosing Bash as the interpreter. The echo command prints a line, read collects what the person types into a variable named name, and the dollar sign in front of a name inserts that stored value. The last command lists the files in the current place. Run this file and Bash works through it top to bottom, asking a question, greeting you by name and showing the folder contents.
📂 How to Open a BASH File
Since a BASH file is plain text, opening it to read is simple, and the choice of tool depends on whether you want to inspect it or edit it.
A text editor
Open it in a plain editor to read the commands, on any system, with nothing special needed.
A code editor
An editor like VS Code colours the syntax and makes a longer script far easier to follow.
The terminal, to run it
To actually carry out the commands, you run the file in a terminal rather than opening it.
Looking a BASH file over before you run it is always wise, since it is a set of commands that will act on your system, and a plain editor lays those commands bare. A code editor is friendlier for anything longer, colouring the parts and spotting mistakes. Opening the file to read and running it to act are two separate things, which leads on to how you actually run one.
▶️ How to Run It
Running a BASH file happens in a terminal, and there are two common ways to do it. The difference comes down to whether the file has permission to run on its own.
Pass it to Bash
Type bash script.sh and Bash runs the file directly. No permission change is needed for this.
Make it executable
Run chmod +x script.sh once, then run it with ./script.sh as though it were a command.
The quickest route is to hand the file to Bash with bash script.sh, which works straight away. The tidier route, and the standard one for scripts you keep, is to grant the file execute permission with chmod +x and then run it with a leading ./. That ./ is important, because on Linux the current folder is deliberately left out of the search path for safety, so you tell the system to run the file right here rather than looking elsewhere for a command of the same name.
bash script.sh for a quick one-off, or chmod +x once and then ./script.sh for a script you keep. The leading ./ tells Linux to run the file in the current folder.
🔢 Passing Arguments
Part of what makes a BASH file so handy is that you can feed it values when you run it, so the same script can act on different files or settings without being rewritten. These values are called arguments, and the script reaches them through numbered names.
When you run a script followed by extra words, Bash makes each one available inside the file. The name of the script itself is held in the first positional parameter, and the values you pass become the ones after it, so the first value is in one, the second in the next, and so on. Two more names are useful here, since one holds the count of values passed, which lets a script check it received enough, and another stands for all of them together. A well-behaved script often checks the count first and prints a short usage message when something is missing, rather than failing halfway through.
A script that greets whoever you name
#!/bin/bash # $1 is the first value you pass in if [ $# -lt 1 ]; then echo "Usage: $0 name" exit 1 fi echo "Hello, $1"
Run this as ./greet.sh Sam and the script sees Sam as its first value and greets that name, while running it with nothing prints the usage line and stops. This pattern, reading numbered values and checking how many arrived, turns a fixed script into a flexible tool you can point at whatever you need.
⚖️ .sh vs .bash
You will see shell scripts ending in both .sh and .bash, and the difference is a useful one to understand, though in daily use it is small.
The .sh extension is the general label for a shell script and hints that the file should work with a basic shell, following the widely shared portable standard. The .bash extension says more specifically that the file is written for Bash and may use Bash-only features such as arrays or richer tests. Bash is a superset of the basic shell, meaning it understands everything the plain shell does and adds extras on top, so a script written for the plain shell runs fine under Bash, while a Bash-specific script may fail if run with a plainer shell. In practice many Bash scripts still use .sh out of habit, and the shebang line is the reliable guide to which interpreter a file really wants.
| Trait | .sh | .bash |
|---|---|---|
| Signals | A general shell script | Specifically a Bash script |
| May use Bash extras | ✗ Best avoided | ✓ Yes |
| Runs under plain shell | ✓ Usually | ~ Only if no Bash extras |
| The real guide | The shebang line, not the extension | |
🔧 .bashrc and .bash_profile
If you have searched for Bash files you have probably met two names that look like scripts but do a different job, .bashrc and .bash_profile. They are worth explaining, because confusing them with an ordinary script you run is a common mix-up.
These two are Bash startup files, hidden configuration files that live in your home folder and run automatically when a shell opens, rather than files you launch by hand. The difference between them comes down to when each one runs. Your .bash_profile runs once when you log in, whether at the machine or over a remote connection, and is the usual place to set environment variables and adjust your path. Your .bashrc runs every time you open a new terminal window or tab in an already-logged-in session, and is where people keep aliases, shell functions and prompt tweaks so they appear in every window. Because so many customisations belong in both situations, a very common habit is to have .bash_profile call .bashrc, so a single set of settings applies everywhere.
| File | When it runs | Usually holds |
|---|---|---|
| .bash_profile | Once, at login | Environment variables, the path |
| .bashrc | Every new terminal window | Aliases, functions, prompt tweaks |
| A .bash or .sh script | When you run it | The commands you want to carry out |
🪟 Bash on Windows
Bash belongs to the Linux and Unix world, so a BASH file does not run on Windows out of the box. There are, however, several tried and tested ways to use one there.
The most complete is the Windows Subsystem for Linux, which runs a real Linux environment inside Windows and handles Bash scripts as Linux would. Git for Windows also includes a tool called Git Bash that runs many scripts, and older setups used Cygwin to bring Unix commands to Windows. One frequent snag when moving scripts from Windows to Linux is invisible line endings, since Windows marks the end of a line differently and Bash can stumble over the extra character. A small tool called dos2unix cleans this up. For anyone working mainly on Windows, the Subsystem for Linux is usually the smoothest way to run and write Bash scripts.
🔍 Debugging a Script
When a script does not behave as expected, Bash has built-in ways to show you what is happening, which saves a great deal of guesswork. Two small additions cover most needs.
The first is trace mode, turned on by running the file with bash -x script.sh, which prints each command as it runs with its values filled in, so you can watch the script step through and spot where it goes wrong. You can also switch this on for part of a file by adding set -x at a point inside it and set +x to turn it off again. The second is stopping on the first error. By default a script keeps going even after a command fails, which can hide the real problem, so adding set -e near the top tells Bash to stop as soon as any command fails, making a broken step obvious rather than letting later commands run on bad results. Together these turn a silent, puzzling script into one that tells you where and why it stopped.
bash -x to print each command as it happens, and add set -e to make the script stop at the first failure instead of pressing on with bad results.
🛡️ Is It Safe to Run?
A BASH file is a list of commands that will act on your computer, so it deserves the same caution as any program from an unknown source. The good news is that, because it is plain text, you can see exactly what it will do before you run it.
A script can do anything you could do at the terminal, which includes changing or deleting files, so a careless or hostile one can cause real harm. The sensible habit is to open a file you did not write in a text editor and read it first, and to be wary of instructions that tell you to run a script downloaded from the internet without looking at it. Scripts from trusted sources and official projects are routine and safe, and reading through an unfamiliar one, or asking someone who knows, is the simple way to stay on the safe side. Because the file hides nothing, a moment spent reading it is usually all the protection you need.
🏛️ A Short History
Bash was written by Brian Fox for the GNU project and released in 1989 as a free replacement for the older Bourne shell, the standard Unix shell of the time. The playful name, Bourne Again SHell, nods to that heritage while marking a fresh start.
Over the decades Bash became the default shell on most Linux distributions and, for many years, on Apple's macOS as well, until macOS moved its default to a different shell called zsh in 2019. Bash is still available on macOS and remains the everyday shell across the Linux world, so shell scripts written for it are as common as ever. Its long reign means that a huge amount of automation, from personal scripts to the systems that build and deploy software, is written as Bash files.
🛠️ Common Issues
A few problems come up again and again with BASH files, and each has a quick explanation and fix.
| Permission denied | The file lacks execute permission. Run chmod +x script.sh, then run it again. |
| Command not found | You left off the leading ./. Run it as ./script.sh from its folder. |
| Odd errors after editing on Windows | Windows line endings. Run dos2unix script.sh to fix them. |
| Works with bash but not with sh | The script uses Bash-only features. Run it with Bash, or set the shebang to #!/bin/bash. |
❓ Frequently Asked Questions
A BASH file is a shell script, a plain-text file holding a list of commands that the Bash shell runs one after another. Bash stands for Bourne Again SHell, the command interpreter built into most Linux systems, and running the file carries out each command in turn just as if you had typed them at a terminal. These files are used to automate work such as backups, installs and system setup. They usually carry a .bash or .sh extension, though on Unix they often have no extension at all, since a special first line decides how the file runs.
Because a BASH file is plain text, you can open it in any text editor to read the commands, on any system and with nothing special needed. A code editor such as VS Code is friendlier for longer scripts, since it colours the syntax and flags mistakes. Reading a script before running it is wise, because it will act on your system, and a plain editor shows exactly what it will do. Opening the file to read it and running it to carry out the commands are two separate steps, and running happens in a terminal rather than by opening the file.
You run a BASH file in a terminal, and there are two common ways. The quickest is to type bash script.sh, which hands the file to Bash and runs it straight away with no permission change. The tidier way, standard for scripts you keep, is to make the file executable once with chmod +x script.sh, then run it with ./script.sh. The leading ./ matters, because Linux deliberately leaves the current folder out of its command search path, so the ./ tells the system to run the file right here rather than looking elsewhere.
That line is called the shebang, and it is usually the first line of a BASH file. It begins with the two characters hash and exclamation mark, spoken as hash-bang, followed by the path to an interpreter, so #!/bin/bash tells the system to run the file with Bash. When you run the script, the system reads this line to decide which program should carry out the commands. Without it, the file runs under whatever shell is active, which can behave differently between computers. A portable alternative, #!/usr/bin/env bash, finds Bash wherever it is installed.
The .sh extension is the general label for a shell script and suggests the file should work with a basic, widely portable shell. The .bash extension says the file is specifically for Bash and may use Bash-only features such as arrays or richer tests. Bash is a superset of the basic shell, so it understands everything the plain shell does and adds more, which means a plain-shell script runs fine under Bash, while a Bash-specific script may fail under a plainer shell. In practice many Bash scripts still use .sh, and the shebang line is the real guide to which interpreter a file wants.
That message means the file does not have permission to run on its own. On Linux and Unix a file must be marked as executable before you can run it with the ./ style, and a freshly written or downloaded script often is not. The fix is to grant that permission once with chmod +x script.sh, after which ./script.sh works. Alternatively you can skip the permission step entirely by running the file with bash script.sh, which hands it to Bash directly and does not need the executable flag.
Not directly, because Bash belongs to the Linux and Unix world, but there are good options. The most complete is the Windows Subsystem for Linux, which runs a real Linux environment inside Windows and handles Bash scripts as Linux would. Git for Windows includes Git Bash, which runs many scripts, and the older Cygwin brings Unix commands to Windows too. One common snag is line endings, since Windows marks line ends differently and Bash can trip over the extra character, which a small tool called dos2unix fixes. For regular use, the Subsystem for Linux is usually smoothest.
Add the values after the script name when you run it, and the script reaches them through numbered names. The script name itself is held in the first positional parameter, and the values you pass become the ones after it, so the first value is in one, the second in the next, and so on. A special name holds the count of values, letting a script check it got enough, and another stands for all of them at once. A tidy script usually checks the count first and prints a short usage message if something is missing, rather than failing partway through, which makes it far easier to use.
On Linux and Unix the usual way is cron, a built-in scheduler. You add a line to your crontab, a small table of timed jobs, giving the schedule and the full path to your script, and the system runs it for you at those times. It is ideal for recurring work like nightly backups or hourly checks. A few things help it run cleanly, chiefly using the full path to the script rather than a short name, since cron does not know your usual folders, and making sure the file is executable or calling it with bash. Cron jobs run under your account and in the system's local time zone, which is worth remembering on shared servers.
An exit code is a number a script gives back when it finishes, telling whatever ran it whether things went well. By convention zero means success and any other number means some kind of error, and a script sets its own with the exit command, such as exit zero to signal success or exit one for a general failure. This matters because other scripts and automated pipelines check that number to decide what to do next, so a script that reports failure clearly can be relied on inside larger systems. Valid codes run from zero to two hundred and fifty-five, and sticking to zero for success and small numbers for specific errors is the common practice.
Bash has built-in tracing that saves a lot of guesswork. Run the file with bash -x script.sh and it prints each command as it runs with the values filled in, so you can watch the script step through and see where it goes wrong. To trace only part of a file, add set -x where you want it to start and set +x where it should stop. It also helps to make the script stop at the first failure by adding set -e near the top, since by default a script keeps going after a command fails, which can hide the real problem. Together these show you where and why a script stopped.
Running a script with ./script.sh starts a fresh, separate shell that carries out the file and then goes away, so any variables it sets or folders it moves into vanish when it finishes. Running it with source script.sh instead runs the commands in your current shell, so changes it makes, such as setting variables or changing directory, stay in effect afterwards. You use the ./ style for ordinary scripts that do a job and exit, and source when a script is meant to change your current session, which is common for files that set up environment variables. The dot is a short form of source, so . script.sh does the same thing.
It is strongly recommended, though not strictly required. If you always run a file with bash script.sh, you are naming the interpreter yourself, so the file works without a shebang. But if you make the file executable and run it with ./script.sh, the system reads the first line to decide which interpreter to use, and without a shebang it falls back to whatever shell is active, which can behave differently across computers. Putting #!/bin/bash, or the portable #!/usr/bin/env bash, at the top makes the file run consistently everywhere and is a good habit for any script you keep or share.
No, though they are both plain text and both hold Bash commands. A .bashrc file is a startup file, a hidden configuration file in your home folder that Bash runs automatically every time you open a new terminal window, and it is where people keep aliases, functions and prompt settings. A .bash or .sh script is a file you run yourself to carry out a task. The practical difference is that you never run .bashrc by hand, it runs for you when a shell opens, whereas a script does nothing until you launch it. Its companion .bash_profile is similar but runs once at login rather than for every terminal.
No, and this catches people out. When you run a script it starts its own fresh, non-interactive shell, and that kind of shell does not read your .bashrc or .bash_profile, so any aliases or functions you defined there are not available inside the script. This is deliberate, since it keeps scripts predictable no matter whose machine they run on. If a script needs something from your startup files, the usual fix is to define it inside the script itself, or to have the script explicitly load the file it needs. In short, do not rely on your personal shell settings being present when a script runs.
📝 Summary
A BASH file is a shell script, a plain-text file of commands that the Bash shell runs one after another, and it is the everyday way to automate work on Linux and Unix. Bash stands for Bourne Again SHell, written by Brian Fox for the GNU project in 1989 as a free successor to the older Bourne shell, and it is the default shell across most Linux systems. The file usually ends in .bash or .sh, though on Unix it often has no extension at all, because a special first line called the shebang, typically #!/bin/bash, tells the system which interpreter to run it with, and that line rather than the file name is what really decides how it runs. Inside, a script holds the same commands you would type at a terminal, along with variables, input, loops and conditions that let a short file do a great deal. Since the content is plain text, any text editor lets you read a BASH file, and a code editor makes a longer one easier to follow, but you carry out its commands by running it in a terminal. There are two usual ways to run one, either by handing it to Bash with bash script.sh, which needs no permission change, or by making it executable once with chmod +x and then running it with ./script.sh, where the leading ./ tells Linux to run the file in the current folder. The .bash extension signals a script written specifically for Bash, which is a superset of the basic shell and may use extras like arrays, while .sh suggests a more portable plain-shell script. Bash is not native to Windows, so a BASH file there needs the Windows Subsystem for Linux or Git Bash, and moving scripts between systems can trip over line-ending differences that dos2unix resolves. Because a script can run any command on your computer, it is worth reading an unfamiliar one in an editor before running it, which is easy since the file hides nothing.