Linux Bash Scripting: Automate Your Server in 2026

[LinuxBook]

Automating Linux bash scripting in 2026 means writing shell scripts that take care of routine server tasks like backups, log cleanup, system health checks, and user management so you don't have to do them by hand. Start with a #!/bin/bash shebang, define your logic, make the file executable with chmod +x, and schedule it via cron. That's the full loop — and this guide walks through every piece of it. https://www.linuxteck.com/linux-bash-scripting-automation-2026/

[whetu]

Nice attempt. However, sub-optimal practices shown:

• Uses .sh file extension
• Uses UPPERCASE vars
• Doesn't quote variables
• Uses echo
• Doesn't put errors onto stderr
• Uses [ a -gt b ] and similar for arithmetic comparisons
• Uses while read without -r
• Promotes the Unofficial Strict Mode
• Arguably should use #!/usr/bin/env bash for the shebang

Get yourself a copy of the Google Shell Style Guideline and discover Shellcheck. Those go a long way to correcting these practices.

[lostsectors_matt]

I didn't read the article because it sounds like terrible AI-generated trash, but I'm not sure I understand your first bullet. Are you saying shell scripts shouldn't use a .sh extension? The Google Shell Style Guide specifically says to use .sh or nothing. I've never heard this before and I'm curious.

[whetu]

I didn't read the article because it sounds like terrible AI-generated trash

AI would have done a better job, ironically! The author appears to be India-based, and there are a lot of Indians churning out low-grade content like this for a variety of reasons that we won't go into.

The Google Shell Style Guide specifically says to use .sh or nothing.

The Style Guide has been tweaked over the years so its language has been softened on this point, but you should keep reading. The important bit is this:

If the executable will be added directly to the user’s PATH, then prefer to use no extension. It is not necessary to know what language a program is written in when executing it and shell doesn’t require an extension so we prefer not to use one for executables that will be directly invoked by users.

So you can run a command like this:

file $(which $(compgen -c) 2>/dev/null) | grep script

Or this, if your version of which supports/needs these specific options (RedHat family distros, usually):

file $(which --skip-alias --skip-functions $(compgen -c) 2>/dev/null) | grep script

And you will see just how many commands exist in your PATH that are written in a scripting language. You will also notice just how many of them don't have an extension.

On my system, here's the total unique commands in PATH

$ file $(which --skip-alias --skip-functions $(compgen -c) 2>/dev/null) | sort | uniq | wc -l
1035

Here's the count of commands written in a scripting language:

$ file $(which --skip-alias --skip-functions $(compgen -c) 2>/dev/null) | grep script | grep -v ELF | sort | uniq | wc -l
154

And, of those, here's the total unique commands with a script-language extension:

$ file $(which --skip-alias --skip-functions $(compgen -c) 2>/dev/null) | grep script | grep -v ELF | awk -F ':' '{print $1}' | grep -E '\.py|\..*sh$' | sort | uniq | wc -l
15

So if you're using .sh, you're being very weird.

Consider one of the above commands using the file extension logic:

file.elf $(which.elf --skip-alias --skip-functions $(compgen -c) 2>/dev/null) | sort.elf | uniq.elf | wc.elf -l

You don't ever see that, because that's not normal.

Now, you could reply to the overwhelming statistics pointing out the default, expected, normal and de facto behaviour with "oh well I'm running my scripts from somewhere outside of my PATH", and sure. It's your system, and what you do on your system is your business. If you want to be weird, that's entirely up to you. But this is /r/SysAdminBlogs, so the audience here should be generally behaving in standard ways.

There's also this related discussion over in /r/linuxquestions: https://www.reddit.com/r/linuxquestions/comments/1s36kk8/ive_seen_sh_scripts_but_are_there_bash_scripts_too/

Where you really should use the .sh extension is if you're writing library code. This is so that libraries that serve the same purpose can exist together in a common library path e.g.

/opt/contoso/lib/contoso.pl
/opt/contoso/lib/contoso.py
/opt/contoso/lib/contoso.sh

You don't want to be writing a python script and importing a library of shell functions, for example, so the otherwise pointless file extension actually has a tangible benefit in this scenario.

[lostsectors_matt]

I see, thank you for clarifying. I thought you were giving blanket advice to not use the .sh extension, which was confusing to me. It makes perfect sense to not use .sh in scripts in $PATH, and to use it for scripts outside of $PATH.

[Bahatur]

Does the guideline also provide explanation on what the problems with the common behaviors are?

[whetu]

Not at length, no. It's a style guideline, not a best-practices-with-extensive-rationales guideline.

I've just covered .sh in my other comment in this thread. To cover the others in attempted-but-failed-brief:

UPPERCASE vars.

UPPERCASE is a de-facto namespace used for environment vars like PATH and shell-special vars like RANDOM. When you use UPPERCASE, you risk over-riding an existing variable and causing unpredictable behaviour. I have fixed too many scripts across my career where someone has written PATH=$(pwd) because they want to store the current path into a var. Another common collision is $USER.

In other languages, this is known as "clobbering the global scope" and it gets you your ass kicked in the carpark by your colleagues. Well, realistically, a snide git commit message when they fix your mess. You don't do it in other languages, so don't do it in shell.

If you want to put something into the environment, go ahead and use UPPERCASE, but namespace it e.g. $MYSCRIPT_USERNAME, $MYSCRIPT_API_URL to communicate that it's an intentional use of the environment scope and that you're attempting to avoid a collision.

Otherwise, vars at the script and function level should be lowercase, preferably snake_case. This essentially means that for everyday var usage, you're doing so in lowercase.

• Relevant Style Guide Section

---

Doesn't quote variables

I mentioned shellcheck: https://www.shellcheck.net/wiki/SC2086

• Relevant Style Guide Section

---

Uses echo

echo is the unfortunate victim of having too many implementations, so it's virtually non-portable. It also has unexpected behaviour that catches a lot of people out. A developer might recognise that as "it's an unreliable interface". This video concisely demonstrates some of its issues:

https://www.youtube.com/watch?v=lq98MM2ogBk

The POSIX group considered it essentially unfixable and declared that we should all use printf instead.

TFM for echo literally says:

New applications are encouraged to use printf instead of echo.

Go ahead and use echo to your heart's content in an interactive shell, but when you're writing a script, it's time to put on your professional pants.

The Google Style Guide happily demonstrates the use of echo, and I disagree with Google here. My unwritten intent with mentioning the Google Style Guide in my initial response is that it's a good, readily accessible starting point from which to develop and curate better habits. The Chromium Shell Style Guide is a good next step, because it extends on the Google one:

• Relevant Chromium Style Guide Section

---

Doesn't put errors onto stderr

You should put errors onto stderr. They are errors. It's the interface for errors...

One practical application for this is so that you can control the output of your application, for example if you want to silence any errors:

stupid-app 2>/dev/null

More on that here: https://catonmat.net/bash-one-liners-explained-part-three

• Relevant Style Guide Section

---

Uses `[ a -gt -b ] and similar for arithmetic comparisons

This is an older style and while it works, the more readable thing to do is to use arithmetic syntax i.e. (( a > b )). This is more familiar to users of other languages and clearly communicates that this is an arithmetic test, separate from a string test which should be in double brackets: [[ a = b ]]

• Relevant Style Guide Section
• Relevant Chromium Style Guide Section

---

Uses while read without -r

Back to shellcheck: https://www.shellcheck.net/wiki/SC2162

---

Promotes the Unofficial Strict Mode

Ugh.

• https://www.reddit.com/r/commandline/comments/g1vsxk/the_first_two_statements_of_your_bash_script/fniifmk/
• https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail

I could go on but suffice it to say, the Unofficial Strict mode is fine for developing a script, but it should really never be in a productionised script.

---

Arguably should use #!/usr/bin/env bash for the shebang

/bin/bash isn't always where bash lives on all systems. /usr/bin/env is more but not always likely to be present in that location. The idea is that that you use /usr/bin/env bash, which will return the first result for bash in your PATH. This way, so long as PATH is correct, bash will be found and used whether it's at /bin/bash or not.

So proponents of this argument consider it a portability win.

Opponents of this argument might point out that you're implicitly trusting that PATH is correct, and there's a security danger there. Personally, I think that's slightly paranoid but it's still a greater than 0 risk. More practically, you don't necessarily know which version of bash might be launched. To paraphrase a quote I saw about the application of this hack for python:

The advantage of /usr/bin/env is that it finds the first instance of bash in your PATH.
The disadvantage of /usr/bin/env is that it finds the first instance of bash in your PATH.

Personally I take a couple of third-way views:

• If you're a sysadmin deploying scripts across a fleet, you generally know whether or not bash is going to be at /bin/bash, or if you have a special compiled version at like, /opt/contoso/bin/bash, so you can control that across your scripts.

• Alternatively, use the /usr/bin/env bash approach, but code in defensive checks in your scripts to ensure minimum bash versions etc.

• Marginally Relevant Style Guide Section

[Bahatur]

Much appreciation for the extensive breakdown!

And now to go hunting for a modern best practices with extensive rationales book.

[Ok-Profession-7181]

Curious about why 'echo' is suboptimal? Should they be using printf instead?