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)
Most guides to bash history shortcuts exhaustively list all of the shortcuts available to you.
The problem I always had with that was that I would use them once, and then glaze over as I tried out all the possibilities. Then I’d move onto my working day and completely forget them, retaining only the well-known !! trick I learned when I first started using bash.
So most never got committed to memory.
Here I outline the shortcuts I actually use every day.
If you’ve ever used a spreadsheet, you’ve probably used or seen functions for doing date math—in other words, taking one date and adding some number of days or months to it to get a new date, or taking two dates and finding the number days between them. The same thing can be done from the command line using the lowly date command, possibly with a little help from Bash’s arithmetic.
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)
Ever wondered why programming in Bash is so difficult? Bash employs the same constructs as traditional programming languages; however, under the hood, the logic is rather different.
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.