| 17 May 2022 |
 ormaaj | insane are the euo pipefail cultists that never learn. | 08:42:04 |
 mgoerner | So wanting to avoid a class of bugs that already once caused to remove $HOME is refusing to learn? | 08:43:00 |
| ormaaj | It's like cruise control for avoiding bugs. amazing! | 08:44:06 |
| ormaaj | "Hi i need help avoiding this new class of bugs I created by enabling these features!" | 08:45:00 |
| mgoerner | There is no new class of bugs. The observed behaviour would be as is even without the strict mode. I want to extend the reach of that feature. | 08:47:20 |
| mgoerner | There is a crash not happening I want to happen. It neither would not happen without strict mode. | 08:48:19 |
 rudolff | Sish there! mgoerner: You might want to try some deeper trace if you curious on that part, but mist likely you are right with the subshell.
Unfortunately, I got off to use any switches for production grade stuff. Yes, I know, you need to check edge cases manually, but it still worth it if you are doing dangerous stuff.
Also, it is sad that these options are flaky, these should be inherited and well of exiting the script if the author wants that. | 08:52:01 |
| ormaaj | It does reliably predict errors in fact. I have never once seen a script with that at the top that is not an absolute turd. Its presence is a convenient warning label for the terrible code that follows. | 09:02:22 |
| mgoerner | I really appreciate your constructive arguments. I am still waiting for you to address the points I brought up above, though. | 09:03:56 |
| ormaaj | The central problem is nothing to do with the hopelessly fubar implementation of set -e. That's just insult to injury. Fundamentally, shell lacks exception handling. The shell uses exit status as the basis for all logic and control flow throughout the language. The unix process model lacks a means of signaling errors that disambiguate them from such logic (in ways that are easily accessible to a shell script). If your logic is wrong you're just going to do dumb stuff like delete important data. There is no way to just use a false exit status as a meaningful exception handling mechanism and trying to explicitly categorize every command even if there were a less terrible method is still crazy wrong. The control logic of a script can be and very often is inverted in a way that would cause the exact problems you're trying to avoid. It isn't actually hard to test for error conditions selectively. Properly testing the results of commands is vastly better than modifying the entire logic of your scripts in such a pathological way.
In fact every mechanism that causes unhandlable errors that force termination are pathological. They all preclude designing in logic to handle particular exceptional conditions according to the specific situational circumstances. Critical code that must handle errors correctly is the worst place to turn on autopilot. Testing and catching mistakes in advance is not super tough. | 09:34:43 |
| ormaaj | Accounting for every quirk in the shell can be a little tough but set -eu really won't help you there. | 09:37:34 |
| rudolff | mgoerner: Tried your code in termux with bash -x and for me it was working as intended. Passed a declare -p and a simple echo on the end, but those were never reached. | 09:39:58 |
| ormaaj | pipefail otoh has a few rare appropriate use cases. Usually you'd enable it temporarily where it's needed. PIPESTATUS and other features like process substitutions largely eliminate the need for it. | 09:40:03 |
 NRK | i agree with ormaaj, exit statuses are not reliable way to detect "errors" as many programs will use a non-zero exit status even if they succeed. | 10:41:37 |
| NRK | it can be useful at times for dead simple scripts with no control flow,
cmd1
cmd2
cmd3
but for anything else, i'd handle errors explicitly rather than relying on set -e | 10:44:41 |
| NRK | * it can be useful at times for dead simple scripts with no control flow,
cmd1
cmd2
cmd3
but for anything else, i'd handle errors explicitly rather than relying on set -e and then having to dance around it's weird rules. | 10:45:46 |
 marcthe12 | Yep, better to do
cmd || exit $?
| 11:59:01 |
| marcthe12 | wherever required
| 11:59:21 |
|  kyushuadamu joined the room. | 12:13:13 |
 antikythera | How to alias a command in a bash script to another command? | 18:12:49 |
| antikythera | for example how to make jq calls in the script to actually invoke gojq | 18:13:07 |
| rudolff | In reply to @leibniz:matrix.org
How to alias a command in a bash script to another command? Aliases are not working within a script. Best always to use full path. | 18:37:19 |
| rudolff | You may try workarounds. You can use variables instead, or link your binary into a directory which is ahead in the search order in $PATH (just brainstorming) | 18:40:33 |
| rudolff | IMHO, if you need to process JSON, you may want to write it in something else than bash. | 18:42:10 |
| ormaaj | In reply to @leibniz:matrix.org
for example how to make jq calls in the script to actually invoke gojq jq() { gojq "$@"; }; | 19:37:22 |
| ormaaj | No clue whether that's actually smart in your case but that's the most generic solution. | 19:43:51 |
| rudolff | Neat! Ofc I forgot the most obvious... | 21:23:29 |
| 18 May 2022 |
 those who know me have no need of my name | FYI, exit $? is redundant as just exit does the same. | 00:39:57 |
|  Arya (dont pm without reason) changed their display name from Arya (aryak.ml) to Arya (dont pm without telling me in a public room). | 11:23:38 |
| Arya (dont pm without reason) changed their display name from Arya (dont pm without telling me in a public room) to Arya (dont pm without reason). | 11:36:39 |
