New answers tagged

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