esa

Quotes are OK, shellcheck is happy, but, according to gtfobins, you can abuse tar, so running the script like this: ./test.sh /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/sh ends up spawning an interactive shell…

This runs into a part of the unix philosophy about doing one thing and doing it well: Extending programs to have more (absolutely useful) functionality winds up becoming a security risk. The shell is generally geared towards being a collection of shortcuts rather than a normal, predictable but tedious API.

For a script like that you’d generally want to validate that the input is actually what you expect if it needs to handle hostile users, though. It’ll likely help the sleepy users too.

Yeah agreed on the 100 lines, or some other heuristic in the direction of “this script will likely continue to grow in complexity and I should switch to a language that’s better suited to handle that complexity”.

I think I mentioned it, but inverse: The only data type I’m comfortable with in bash are simple string scalars; plus some simple integer handling I suppose. Once I have to think about stuff like "${foo[@]}" and the like I feel like I should’ve switched languages already.

Plus I rarely actually want arrays, it’s way more likely I want something in the shape of

@dataclass(frozen=True)
class Foo:
    # …

foos: set[Foo] = …

-e is great until there’s a command that you want to allow to fail in some scenario.

Yeah, I sometimes do

set +e
do_stuff
set -e

It’s sort of the bash equivalent of a

try { 
  do_stuff()
} 
catch { 
  /* intentionally bare catch for any exception and error */
  /* usually a noop, but you could try some stuff with if and $? */ 
}

I know OP is talking about bash specifically but pipefail isn’t portable and I’m not always on a system with bash installed.

Yeah, I’m happy I don’t really have to deal with that. My worst-case is having to ship to some developer machines running macos which has bash from the stone ages, but I can still do stuff like rely on [[ rather than have to deal with [ . I don’t have a particular fondness for using bash as anything but a sort of config file (with export SETTING1=... etc) and some light handling of other applications, but I have even less fondness for POSIX sh. At that point I’m liable to rewrite it in Python, or if that’s not availaible in a user-friendly manner either, build a small static binary.

The logs are handled, but I mostly use it for command separation and control, including killing unruly child processes.

At the level you’re describing it’s fine. Preferably use shellcheck and set -euo pipefail to make it more normal.

But once I have any of:

• nested control structures, or
• multiple functions, or
• have to think about handling anything else than simple strings that other programs manipulate (including thinking about bash arrays or IFS), or
• bash scoping,
• producing my own formatted logs at different log levels,

I’m on to Python or something else. It’s better to get off bash before you have to juggle complexity in it.

There also are some stories from js devs about how async/await reduced the spaghetti factor of their code a lot. So yeah, similar stories all around I think, even though async/await obviously isn’t a magical thing with no downsides

Yeah, Rust is ultimately a different project than Go, and I suspect much of the success of Go is down to stuff like good tooling, default GC, native static binaries, generally easy concurrency, rather than stuff like having as bare-bones a language as otherwise possible. I’d suspect having a focus on fast compilation also helps draw in people from interpreted languages.

It’s easy to write a Kubernetes microservice that performs adequately with Go, and that’s all a lot of people & teams need.

Yeah, the Go creators seem to generally mean “resembles C” when they use words like “simple”, which could explain stuff like going “why do you need generics when you can just cast?” for, what, ten years?

I remember trying some Plan9 stuff and bouncing off it, including acme. I guess it’s the kind of thing that makes sense to Pike but not to me. Not sure what gophers in general think of it (but wikipedia lists at least Russ Cox as a user).

I suspect my habit of having an alias userctl="systemctl --user" is slightly unusual, as is running Firefox, Steam, and some other graphical programs as systemd units is somewhat unusual (e.g. mod4-enter runs systemd-run --user alacritty)

But what I’m actually pretty sure is unique is my keyboard layout. I taught myself dvorak a summer some decades ago, but the norwegian dvorak layout has some annoyances, so I’ve made some tweaks. Used to be a Xmodmap file, but with the switch to wayland I turned it into a file in /usr/share/X11/xkb/symbols/.

Part of what I did to teach myself dvorak and touch-typing at the same time was randomize the placement of the keycaps too. It has a side effect of being a kind of security by obscurity layer: I type quickly and confidently, but others who want to use my machines have an “uhh …” reaction.

This comes off as a weird mash of ideas, and it’s not clear what they mean by “traditional programming languages”—the link seems to include Typescript, which is younger than Rust, which is _not_presented as a “traditional” programming language.

The whole thing comes off as … something a Murdoch-owned site would dream up, maybe?

Depends on your problem. Newer languages seem to have much better docs than in the old days, so languages like Rust, Go and Typescript seem very underrepresented by Stackoverflow activity compared to public Github activity.

By that logic we would still be using horses since technically we don’t -need- cars.

Most of us would be using our feet and transit (and possibly bikes); both our households and our economies would be better off financially and bodily if car use was restricted to goods hauling and some few other uses (not to mention the environment). Mass motorism has turned out to be mostly a way to enrich the auto industry, not our societies, with North America as a warning to the rest of us. (See !fuckcars@lemmy.world for more.)

There are plenty of times where humanity has chased the latest fad without considering the costs & benefits properly. The amount of energy and hardware being blown away on LLMs are another example; same goes for creepto and NFTs.

That said, having a look around for various applications, including terminals, is generally good. If someone finds something that covers their needs but with lower costs, that’s good. And if they find something with a shiny new bell or whistle at exorbitant cost, eh, maybe think twice before choosing it.

Ah, so we didn’t have to wait until 2038.

Yeah, that’s what I do for complex stuff. Aliases are pretty handy too, but I use them for stuff like “v=nvim” and “vd=nvim -d”. Also one function for fd to “nvim $(rf -l $1)”

And very old. Part of the sales pitch for the COmmon Business-Protected Language was that anyone could learn to code in almost plain English.

Also, the stuff they wind up making is the kind of stuff that people with no coding experience make. Cooking up an ugly website with terrible performance and security isn’t much harder than making an ugly presentation with lots of WordArt. But it never was, either.

Between COBOL and LLM-enhanced “low code” we had other stuff, like that infamous product from MS that produced terrible HTML. At this point I can’t even recall what it was called. The SharePoint editor maybe?

Yeah, Rust tries to find as many problems as it can during compilation. It’s great for those of us who want the bugs to be found ahead of release, not great for those who just want something out the door and worry about bugs only after a user reports them.

Different platforms have different values, and that also affects what people consider fun. At the other end of the scale you find the triple-equals languages like js and php, which a lot of people think are fun and normal, but some of us think are so wobbly or sloppy that they’re actually much harder languages than other, stricter languages.

If you value correctness and efficiency, Rust is pretty fun.

I think I’ll stick to alacritty, but options are always fun

US? Here in scandi tax seems to work well automatically, as in, we just log into the government website and click OK most years. Corrections are easy enough too, if you need it, but it’s usually not required.

Idunno, that might be approaching “one day of patchy electricity can change how you view computers vs mechanical typewriters”. Here people would likely use their mobile internet, especially if the company is paying their phone bill.