New answers tagged bash
6
Shots from the hip, three decades since I seriously programmed shell notwithstanding:
document your code - in the code.
The comments presented are a good start - in the middle, irritatingly.
What is the whole script useful for, how shall it be used?
You can even have executable comments:
if called incorrectly or with -h, --help (or even -?), print a
Usage: ...
2
I'm writing a bash script to search C source files and find the lines where I missed the void keyword
This alone suggests that your approach is very problematic. To do this properly you'd effectively need to write most of a C parser, and that isn't a good use of your time. There are other approaches that would get you more mileage and accuracy:
Double-...
2
I think the modified date doesn't change when the file is moved to #Recycle area, so if the file is already older than 60 days, it will deleted the next time the script runs.
I have observed that the 'change' date gets reset when moved to a new directory. Do a 'stat' or 'ls -lc' of the file before and after moving to different directory and you should see ...
3
Use the -u and -e switches to bash, when possible, because they help to find bugs. Your log decoder may return errors that you want to ignore (making -e unhelpful) but -u is safe here.
Move the echo … exit pattern into a function:
die() { printf "%s\n" "$@" >&2; exit 1; }
Quotes aren't needed on the left-hand side of [[ tests. For "die unless foo"...
2
Always set up the trap before trying to create the directory. Otherwise there's a race condition where the script may die after creating the directory but before having a chance to clean it up. And use single quotes for the trap command to make sure the variable is only expanded at exit:
trap 'rm -rf "$tmpdir"' EXIT
tmpdir="$(mktemp -d)"
If the trap ends ...
Top 50 recent answers are included
