There is some truth to what you say, but bash has functions, which largely mitigate it. The easiest way to make bash sane is to put everything in functions. Then everything can be tested interactively. I don't know why people put 300+ lines of code at the top level -- that makes changes very difficult to test.
A good trick for this is to put:
"$@"
at the bottom when you are testing. Then you can do:
./myscript.sh func-name arg1 arg2 ..
If you really want, you can change it to
main "$@"
before deploying so it only runs the main function. Those lines, and constants, should be the ONLY things at the top level of a bash script IMO (even a 10 line one).
Don't stare at bash code without running it -- that's crazy. I have taught Python and also admonish people to not "stare" at their code; just form a hypothesis and run it. I suspect this is where Haskellers have problems, because they think that not running your code is a good thing.
I love shell; it's one of my favorite languages now. I don't think there are really that many warts once you know it. You're right that set -e and set -u are generally code ideas, along with set -o pipefail.
"Don't stare at bash code without running it -- that's crazy. I have taught Python and also admonish people to not "stare" at their code; just form a hypothesis and run it. I suspect this is where Haskellers have problems, because they think that not running your code is a good thing."
This was awesome. And, I agree, probably close to the mark.
It is somewhat odd in this day and age when computers do run so bloody fast that so much effort seems to be spent in not just running an application.
Of course, this is clearly easy to take too far. I feel that a lot has been lost by folks that did not first draft out their intentions on paper. (Well, at least I know I have wasted a fair bit of time in that regard.)
A good trick for this is to put:
at the bottom when you are testing. Then you can do: If you really want, you can change it to before deploying so it only runs the main function. Those lines, and constants, should be the ONLY things at the top level of a bash script IMO (even a 10 line one).Don't stare at bash code without running it -- that's crazy. I have taught Python and also admonish people to not "stare" at their code; just form a hypothesis and run it. I suspect this is where Haskellers have problems, because they think that not running your code is a good thing.
I love shell; it's one of my favorite languages now. I don't think there are really that many warts once you know it. You're right that set -e and set -u are generally code ideas, along with set -o pipefail.