6 ms·
Thanks for the 'use warnings;' suggestion. Keep in mind the subject here is maintainence - where small changes with minimal impact to production is the rule an
by amenbrother 12y ago
Thanks for the 'use warnings;' suggestion.
Keep in mind the subject here is maintainence - where small changes with minimal impact to production is the rule and the work is often done by programmers with incomplete knowledge and no patience for explanations. For maintenance you want KISS, not TMTOWTDI.
I'm no big fan of bash but at least bash gets the common case right here without any special settings. For example, if I use -eq instead of == and write
#!/bin/bash
x=`cat FOO 2>/dev/null`
if [ $x -eq 'bar' ]; then
echo baz
fi
as you imply, bash won't be silent. It will say
bash-3.2$ ./example.sh
./example.sh: line 3: [: bar: integer expression expected
- mst 12y agoEqually, bash requires 'set -x' to not ignore errors. In both cases, the reasoning is significantly to do with backcompat, I believe. So, yeah, things that have been around a long time often require a setting to be safe in cases that we, ten or twenty or whatever years on, consider common. Also: I did keep that in mind. That's why I started off suggesting using warnings, rather than (as I normally do for new code) making them fatal :)