My heart goes out to shell programmers who have to support posix sh

It is different in spoken form, written form (chat) and written as a post (like here).

In person, you get a reaction almost immediately. Written as a short chat, you also get a reaction. But like this is more of an accessibility thing rather than the joke not being funny. You know, like those text descriptions of an image (usually for memes).

I really recommend that if you haven't, that you look at the Bash's man page.

It's just amazing.

The issue with set -e is that it's hideously broken and inconsistent. Let me copy the examples from the wiki I linked.

---

Or, "so you think set -e is OK, huh?"

Exercise 1: why doesn't this example print anything?

#!/usr/bin/env bash
set -e
i=0
let i++
echo "i is $i"

Exercise 2: why does this one sometimes appear to work? In which versions of bash does it work, and in which versions does it fail?

#!/usr/bin/env bash
set -e
i=0
((i++))
echo "i is $i"

Exercise 3: why aren't these two scripts identical?

#!/usr/bin/env bash
set -e
test -d nosuchdir && echo no dir
echo survived 

#!/usr/bin/env bash
set -e
f() { test -d nosuchdir && echo no dir; }
f
echo survived

Exercise 4: why aren't these two scripts identical?

set -e
f() { test -d nosuchdir && echo no dir; }
f
echo survived

set -e
f() { if test -d nosuchdir; then echo no dir; fi; }
f
echo survived

Exercise 5: under what conditions will this fail?

set -e
read -r foo < configfile

---

And now, back to your regularly scheduled comment reply.

set -e would absolutely be more elegant if it worked in a way that was easy to understand. I would be shouting its praises from my rooftop if it could make Bash into less of a pile of flaming plop. Unfortunately , set -e is, by necessity, a labyrinthian mess of fucked up hacks.

Let me leave you with a allegory about set -e copied directly from that same wiki page. It's too long for me to post it in this comment, so I'll respond to myself.

Yeah, while -e has a lot of limitations, it shouldn't be thrown out with the bathwater. The unofficial strict mode can still de-weird bash to an extent, and I'd rather drop bash altogether when they're insufficient, rather than try increasingly hard to work around bash's weirdness. (I.e. I'd throw out the bathwater, baby and the family that spawned it at that point.)

This is why I made the reference to Go. I honestly hate Go, I think exceptions are great and very ergonomic and I wish that language had not become so popular. However, a whole shitload of people apparently disagree, hence the popularity of Go and the acceptance of its (imo) terrible error handling. If developers don't have a problem with it in Go, I don't see why they'd have a problem with it in Bash. The error handling is identical to what I posted and the syntax is shockingly similar. You must unpack the return of a func in Go if you're going to assign, but you're totally free to just assign an err to _ in Go and be on your way, just like you can ignore errors in Bash. The objectively correct way to write Go is to handle every err that gets returned to you, either by doing something, or passing it up the stack (and possibly wrapping it). It's a bunch of bubbling up. My scripts end up being that way too. It's messy, but I've found it to be an incredibly reliable strategy. Plus, it's really easy for me to grep for a log message and get the exact line where I encountered an issue.

This is all just my opinion. I think this is one of those things where the best option is to just agree to disagree. I will admit that it irritates me to see blanket statements saying "your script is bad if you don't set -euo pipefail", but I'd be totally fine if more people made a measured recommendation like you did. I likely will never use set -e, but if it gets the bills paid for people then that's fine. I just think people need to be warned of the footguns.

EDIT: my autocorrect really wanted to fuck up this comment for some reason. Apologies if I have a dumb number of typos.

I was tempted for years to use it as an occasional try/catch, but learning Go made me realize that exceptions are amazing and I miss them, but that it is possible (but occasionally hideously tedious) to write software without them. Like, I feel like anyone who has written Go competently (i.e. they handle every returned err on an individual or aggregated basis) should be able to write relatively error-handled shell. There are still the billion other footguns built directly into bash that will destroy hopes and dreams, but handling errors isn't too bad if you just have a little die function and the determination to use it.

God I love bash. There's always something to learn.

my logical steps

• #! yup
• if sure!
• [[ -z makes sense
• ${1:-} WHAT IN SATANS UNDERPANTS.... parameter expansion I think... reads docs ... default value! shit that's nice.

it's like buying a really simple generic car then getting excited because it actually has a spare and cupholders.

That's good, but if you like to name your arguments first before testing them, then it falls apart

#!/bin/bash
set -euo pipefail

myarg=$1

if [[ -z "${myarg}" ]]
then
  echo "we need an argument!" >&2
  exit 1
fi

This fails. The solution is to do myarg=${1:-} and then test

Edit: Oh, I just saw you did that initialisation in the if statement. Take your trophy and leave.

Your scientists were so preoccupied with whether they could, they didn’t stop to think if they should

Aka busybox in disguise 🥸

Wouldn't something interpreted like python be a better solution?

That's sounds terrible honestly

Nushell is great as a more powerful scripting language, but a proper language like python is useful too

Yeah, I had a silly hack for that. I don't remember what it was. It's been 3-4 years since I wrote bash for a living. While not perfect, I still need to know if a pipeline command failed. Continuing a script after an invisible error, in many cases, could have been catastrophic.

People keep on telling me that python is a "scripting language" but honestly I would rather use the shoddiest and most barebones shell you would give me than python if I had to make a script. It all boils to interfaces, and there are more programs, libraries, and daemons that have a shell interface as opposed to whatever other "better" language there is out there. Trying to write scripts with Python or ruby or whatever will just boils down to plumbing data between external programs in a less succinct syntax. What good is type safety, try/catch, and classes if all the tools that you're using are taking in and spitting out raw text anyway?

$time = (get-date).adddays(-30)
gci -file -filter *.pdf `
  | ? { $_.lastwritetime -gt $time } `
  | % { convert -density 300 $_.fullname $($_.fullname + ".jpg") }

🤷

The .net-ification of *nix just seems bonkers to me.

It IS bonkers. As a case study, compare the process of setting up a self-hosted runner in gitlab vs github.

Gitlab does everything The Linux Way. You spin up a slim docker container based on Alpine, pass it the API key, and you're done. Nice and simple.

Github, being owned by Microsoft, does everything The Microsoft way. The documentation mentions nothing of containers, you're just meant to run the runner natively, essentially giving Microsoft and anyone else in the repo a reverse shell into your machine. Lovely. Microsoft then somehow managed to make their runner software (reminder: whose entire job consists of pulling a git repo, parsing a yaml file, and running some shell commands) depend on fucking dotnet and a bunch of other bullshit. You're meant to install it using a shitty setup.sh script that does that stupid thing with detecting what distro you're on and calling the native package manager to install dependencies. Which of course doesn't work for shit for anyone who's not on debain or fedora because those are the only distro's they've bothered with. So you're either stuck setting up dotnet on your system, or trying to manually banish this unholy abomination into a docker container, which is gonna end up twice the size of gitlab's pre-made Alpine container thanks to needing glibc to run dotnet (and also full gnu coreutils for some fucking reason)

Bloat is just microsoft's way of doing things. They see unused resources, and they want to use them. Keep microsoft out of linux.

What type of .net-ification occurs on *nix? I am current linux "admin" and there is close to 0 times where I've seen powershell not on windows. Maybe in some microsoft specific hell-scape it is more common, but it's hard to imagine that there are people that can accept a "shell" that takes 5-10 seconds to start. There are apps written in c# but they aren't all that common?

I usually only use the terminal when I don't find an alternative, but powershell usually feels a bit saner than bash.

I've also tried nushell, also nice, but in a few situations powershell despite usually being verbose was more "elegant".

that is a little more complicated

p.communicate() will take a string (or bytes) and send it to the stdin of the process, then wait for p to finish execution

there are ways to stream input into a running process (without waiting for the process to finish), but I don't remember how off the top of my head

from shutil import which
from subprocess import Popen, PIPE, run
from pathlib import Path

LS   = which('ls')
REV  = which('rev')

ls   = run([LS, Path.home()], stdout=PIPE)

p = Popen([REV], stdin=PIPE, stdout=PIPE)
stdout, stderr = p.communicate(ls.stdout)

print(stdout.decode('utf-8'))

I do not envy you.

Lua