Master Bash scripting with our guide on how to verify if a file or directory exists. Includes examples and best practices for reliable scripts.
Tag: bash script
Explains how to check if a bash shell script is being run or executed by the root user account under Linux, macOS, Unix and BSD.
In the course of my career, I’ve periodically come across code like this in shell scripts:
Or sometimes, slightly more elegantly:
The problems with the first example are obvious, especially if it appears in many different scripts. The second is better. The “$$” means “my process ID”, who if whatever script had a process ID of 5309, the TEMPFILE variable would be set to /tmp/tempfile.5309. This makes collisions between scripts extremely unlikely, but is still suboptimal. What if there is a file called /tmp/tempfile.5309 and it’s owned by another user, or what if you don’t have permission to write to /tmp? It’d be better to find out immediately than many lines later when you try to write something. …
The following concepts modernize your automation scripts with some lesser-known modern Bash scripting techniques.
This guide explains how to use date command in Bash scripting and how to work with date and time in shell scripts in Linux.
When spending most of your day around bash shell, it is not uncommon to waste time typing the same commands over and over again. This is pretty close to the definition of insanity.
Luckily, bash gives us several ways to avoid repetition and increase productivity.
Today, we will explore the tools we can leverage to optimize what I love to call “shell time”.
Minimal Bash script template that will make your scripts safer, consistent with standards, and provide a way to parse and validate parameters.
Writing shell scripts leaves a lot of room to make mistakes, in ways that will cause your scripts to break on certain input, or (if some input is untrusted) open up security vulnerabilities. Here are some tips on how to make your shell scripts safer.
Source: Writing Safe Shell Scripts (MIT Student Information Processing Board)
I call this the unofficial bash strict mode. This causes bash to behave in a way that makes many classes of subtle bugs impossible. You’ll spend much less time debugging, and also avoid having unexpected complications in production.
Source: Use the Unofficial Bash Strict Mode (Unless You Looove Debugging) (aaron maxwell)
Every so often something really useful appears on Reddit, and this is such a case. You may encounter a situation where you want to execute the contents of a bash script, but not more frequently than every few seconds. A Reddit user wanted to know How to check if a command in .bashrc has been executed within last 10 seconds if yes don’t execute the command again. The response by Reddit user mdaffin is brilliant in its simplicity, and can be used in any bash script where you don’t want the contents executed too often:
Write a time stamp to some file, check said file before you run the command if now – timestamp > 10s run the command and update the timestamp.
EDIT: Like this (with modification times instead):
if [[ ! -f "$TS_FILE" ]] || [[ "$(expr "$(date +%s)" - "$(stat -c %Y "$TS_FILE")")" -gt 10 ]]; then
You’d replace the
echo "running" line with the part of the bash script you want to run only if it’s been 10 seconds since the last time the script was run, or whatever number of seconds you specify after the
-gt. If the bash script actually outputs a file as part of its normal operation then you could specify that file in the
TS_FILE= line; there would be no need to create a separate timestamp file (unless some other process could also modify that same file).
This doesn’t actually stop the bash script from running; it just prevents it from executing the part of the script that you don’t want executed too frequently. This could be very useful in a situation where without such protection, the too-frequent execution of the script might cause something undesirable to happen (such as getting locked out of an online site for hammering it with requests). Depending on the situation there may be other, perhaps even better ways to avoid this possibility, but in other cases this may indeed be the best approach.