Do you like writing shell scripts that just work, no matter how? Do you think, that a script that already works cannot be improved? Do you look down on people doing performance tests on their shell scripts? Do you think comments are unnecessary, because shell scripts are more frequently written then read? Then this article is written just for you!
You probably know the difference between
Just ignore this certainly neglectable difference. If users use file names containing whitespace, they will have other problems than your failing script. Who can expect you to search the "@" key on your keyboard if the "*" key is so near?
Just use for-loops of the following form:
# remove - remove files for file in $* do echo "$file does no longer contain whitespace" rm -f $file done
If somebody calls this remove script with the single argument "/etc/passwd Backup", he should have expected to lose some data.
If you had written the script in one of the following ways it would have worked:
for file in "$@" do # ... doneor shorter:
for file do # "$file" still contains whitespace... done
But why care? Just be sure to include a sentence like "in case of difficulties restore data from the backup" within your documentation.
Some people try to avoid the
Don't believe them! Who cares for script execution speeds
and unnecessary processes?
cat file | grep searchstring
could be rewritten as
grep searchstring < file
and every command of the following form
cat onefile | prog1 | prog2could be rewritten as
prog1 < onefile | prog2but y'know what?
cat onefile | cat | cat | cat | cat | cat | cat | prog1 | prog2
works as well!
You just can't do something wrong using
did not result in an empty output line, but in the
echo "" echo "this line is preceeded by an empty line" echo ""
echo echo "the previous line is empty" echo
Help preserving this last reminiscence of DOS in a windowing world!
Copyright © 1998-2015 Heiner Steven (firstname.lastname@example.org)