This is a great description of things that seem like they shouldn't be so difficult but can have many complications. The SQL part seems to double-down on a conceptual failure rather than demystifying it though. A query's logic is declarative which defines the output. It's the query plan that has any sense of execution order or procedural nature to it. That's the first thing to learn. Then one can learn the fuzzy area…
Making Hard Things Easy
21–30 of 202 posts
Re: Making Hard Things Easy
#22Re: Making Hard Things Easy
#23TiL: 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
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 normally return non-zero in order to do their job of checking a string for a certain pattern or whatever.
Programs are free to return whatever exit codes they want in any circumstance they want, and common convention is to return 0 upon success and non-zero upon failure. But the only thing that the shell is concerned with is that 0 evaluates to "true" and non-zero evaluates to "false" in the language.
It would be pretty inconvenient if the shell exited any time any program returned non-zero, otherwise if statements and loops would be impossible.
If a script should care about the return code of a particular program it runs, then it should check explicitly and do something about it. As you linked to, there are options you can set to make the shell exit if any command within it returns non-zero, and lots of beginner to intermediate shell script writers will _dogmatically_ insist that they be used for every script. But I have found these to be somewhat hacky and full of weird hard-to-handle edge cases in non-trivial scripts. My opinion is that if you find yourself needing those options in every script you write, maybe you should be writing Makefiles instead.
Re: Making Hard Things Easy
#24Earlier quoted context omitted.
I maintain a file with commands that I don't use often (ex: increase volume with ffmpeg, add a border to an image with convert, etc). I even have a shortcut that'll add the last executed command to this file and another shortcut to search from this file.
Oh, that's a great idea. I have a doc that I maintain by hand, either via ">>" or editing directly. Time to go and make a shortcut. Do you do any annotation to help with the search?
Re: Making Hard Things Easy
#25Re: Making Hard Things Easy
#26I 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.
Re: Making Hard Things Easy
#27Re: Making Hard Things Easy
#28Re: Making Hard Things Easy
#29Earlier quoted context omitted.
I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection. The man pages are readily available. The bash man page is huge and hairy, but comprehensive, I've found it pretty valuable to be familiar with the major sections and the visual shape of the text in the man page so I can pag…
> The man pages are readily available. True, but I find the man pages not easy and quick to parse.
I recently found https://tldr.sh/ and found it more convenient. I ended up writing myself a vscode extension to have a quick lookup at my fingertips, since I am at least 60% of the time looking at a terminal in vscode
Re: Making Hard Things Easy
#30I 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.
The problem is with bash itself.
We tend to undervalue ease of use and overvalue "cleverness."
Case in point: git. Very clever tool. Ease of use: terrible. But Linus wrote it and Linus is clever, so it must be us that's the problem.
We get what we value. Let's value ease of use more.