shellcheck is a great idea. But you know what’d be even better? Not having to write bash in the first place.
Julia is right: computers are great at remembering trivia. One of the best demonstrations of this, is compilers: they take in a high-level abstract program, and use a vast repertoire of knowledge about instruction sets, to transform the high-level abstract description of a program, into a program executable on a machine that’s much more awful to program for directly, with many more gotchas.
(Here’s where you say “Hey, wait a minute.”)
Why are we writing bash, when we could be writing programs in a higher-level language that compiles to bash? One with exceptions, at the very least.
(Yes, such a language would need a runtime that wraps every common binary and lifts its stdout + stderr + exit code -based semantics into safe, high level semantics. So what? That’s only 10000 “FFI bindings” or so for anything a normal person or sysadmin would want to call. For everything else, just ensure that writing your own FFI binding, inline to a script, is easy.)
Julia is right: computers are great at remembering trivia. One of the best demonstrations of this, is compilers: they take in a high-level abstract program, and use a vast repertoire of knowledge about instruction sets, to transform the high-level abstract description of a program, into a program executable on a machine that’s much more awful to program for directly, with many more gotchas.
(Here’s where you say “Hey, wait a minute.”)
Why are we writing bash, when we could be writing programs in a higher-level language that compiles to bash? One with exceptions, at the very least.
(Yes, such a language would need a runtime that wraps every common binary and lifts its stdout + stderr + exit code -based semantics into safe, high level semantics. So what? That’s only 10000 “FFI bindings” or so for anything a normal person or sysadmin would want to call. For everything else, just ensure that writing your own FFI binding, inline to a script, is easy.)