If you’re already putting them in a file, you might as well put them in a shell script on $PATH: at a certain point I started writing shell scripts and little utilities for relatively infrequently used commands and other tasks (e.g. clone this repo from GitHub to a well-known location and cd to it)
Wait, how do you “cd to it” from within the script? Doesn’t exiting the script take you back to where you were?
For this I use shell functions in my .zshrc and I wrote a loader to source a bunch of files in a .zsh.d directory.
Is it better to set -e or check return code of processes and decide to exit?
Better/worse is one of those subjective things that comes with experience. No one can definitively answer such a question in a way that will apply to every circumstance. But as someone who rarely writes bash scripts but just enough to be dangerous ... I use `set -xe` at the top of every single shell script I write. The -x flag causes the script to echo every command that is executed to stdout which can be very valuab…
Mine's `set -eEuo pipefail`.
I'd have to look up exactly what's what, but if you're inclined to `-e` you probably want the others too. (Off the top of my head I think E is the same thing in functions, u is bail out if a variable is used without being defined (instead of treating it as empty string), and pipefail is similar for when you pipe to something else like `this_errs | grep something`.)
I don't like `-x` personally, I find it way too verbose; more confusing than helpful.
To make hard things easy you have to find the right way to abstract them so you hold only some bits of the hard things in your head and all the frequently-used details too (maybe), and everything else you have to look up as needed. That's what I do, and that's roughly what TFA says. The problem is that people don't necessarily bother to form a cognitive compression of a large topic until they really have to. That's b…
A possibly radical way of fixing the SQL clause order would be to introduce "project" which behaves like "select" but can be put in the right place.
The part that resonated most with me is "Show things that are normally hidden". Tools that do this make things clearer almost immediately. Consider the developer tools in a web browser. Do you remember the "dark ages" before such things existed? It was awful because you had to guess instead of seeing what was going on. Tools like Wireshark that show you every last byte of network packets that it has access to AND par…
Wireshark is great but it does not show you every byte the network carried. For example it never shows Ethernet preambles, only sometimes shows Ethernet frame checksums, and never shows interpacket gaps (which are a required part of the Ethernet protocol).
So yes it comes close but it just goes to show you, there is always more detail hiding somewhere!
Julia has to be one of the most likable people in tech! Every time I read one of her articles I feel that same bubbly rush of excitement I got when I was a kid, just starting to unfurl the secrets of reality through my own little experiments. Absolutely lovely.
She was LOVELY in person as well. I got her to sign my copy of How DNS Works.
The part that resonated most with me is "Show things that are normally hidden". Tools that do this make things clearer almost immediately. Consider the developer tools in a web browser. Do you remember the "dark ages" before such things existed? It was awful because you had to guess instead of seeing what was going on. Tools like Wireshark that show you every last byte of network packets that it has access to AND par…
Wireshark is great but it does not show you every byte the network carried. For example it never shows Ethernet preambles, only sometimes shows Ethernet frame checksums, and never shows interpacket gaps (which are a required part of the Ethernet protocol). So yes it comes close but it just goes to show you, there is always more detail hiding somewhere!
To be fair, the preamble can be easily considered just an electrical signal due to its objective (sync) which doesn't affect how the network works.
I really disagree strongly with the take on bash. The best solution is not to add tooling on top of bash or memorize its idiosyncrasies. It is to not use bash. That is the only way to escape its pitfalls.
I have yet to find a proper replacement for bash. Especially for scripts. The two most common alternatives are 1) using some of the newer shells people have created, like Oil shell [0], or 2) using programming language like Python, JavaScript, or PHP. The problem with using a newer shell is that you'll have to install the new shell anywhere you want to use the script. Meanwhile bash is ubiquitous. Unless you're the o…
I'll still write bash, but only if it's very trivial (~ <= 10-ish lines, no super-complex conditionals, etc). For anything else, it's worth stepping up to just about any more-robust language. If you don't like the hoops that something like Python makes you go through for basic shell-like operations, maybe try Perl? For middling-complexity scripts, perl can be a nice win over bash, without all the development overhead of Python. Perl5 is pretty much installed everywhere and universally compatible for anything but the very latest language features.
TiL: The shell does not exit if the command that fails is a part of any command executed in a && or || list except the command following the final && or ||. Reference: https://www.gnu.org/software/bash/manual/bash.html#index-set
"Fails" is a higher-level concept than the shell is concerned with. Failure conditions and reactions are entirely at the discretion of the programmer and are not built as an assumption into the shell. The only thing /bin/false does is return 1. Is that a failure? No, that's how it was designed to work and literally what it is for. I have written hundreds of shell scripts and lots of them contain commands which quite…
> It would be pretty inconvenient if the shell exited any time any program returned non-zero, otherwise if statements and loops would be impossible.
In another life I worked as a Jenkins basher and if I remember correctly I had this problem all the time with some Groovy dsl aborting on any non zero shell command exit. It was so annoying.