I like the idea of hard wrap, line of code shouldn't be longer than 80 characters... sure it's confusing for beginners + sometimes data shouldn't be hard-wrapped, but in general (imho) it's better than worse
if [ x$CMDSH = xshell ] ; then
grep -qP $BLKLST <<<"$CMD" && CMD='panic' # skip obviously bad commands like
rm -rf /
# (this isn't a security thing, we just want to catch stupid mistakes)
fi
Have comments containing text that could be interpreted as a call to 'break-the-world(err=/dev/null,filter=const(true))'? Not often, but it only needs to go wrong once.
Checking for obvious problems should happen inside eg rm (see `rm --help | grep root`), not in a random shell script, but I didn't want to bother coming up with a better excuse to have rm -rf / inside a comment.
Usually the errors caused by syntax-unware text mangling are either obvious and harmless (so not as punchy of a example) or much more subtle than "destroys literally the entire system".
Can you explain your thought process here? I believe the idea is that old terminals were 80 characters wide. Also, even with modern monitors it can be nice to have shorter lines so you don't have to move your eyes/head as much. I can't think of why the rule would be specific to source code or why it would apply any differently to other forms of text.