esa @ syklemil @discuss.tchncs.de

Posts

2

Comments

161

Joined

7 mo. ago

Yeah, another way to do it is

 bash

    
#!/bin/bash
set -euo pipefail

if [[ $# -lt 1 ]]
then
  echo "Usage: $0 argument1" >&2
  exit 1
fi

  

i.e. just count arguments. Related, fish has kind of the orthogonal situation here, where you can name arguments in a better way, but there's no set -u

 fish

    
function foo --argument-names bar
  ...
end

  

in the end my conclusion is that argument handling in shells is generally bad. Add in historic workarounds like if [ "x" = "x$1" ] and it's clear shells have always been Shortcut City

Side note: One point I have to award to Perl for using eq/lt/gt/etc for string comparisons and ==/</> for numeric comparisons. In shells it's reversed for some reason? The absolute state of things when I can point to Perl as an example of something that did it better

I'd interpret vertical content growth as content per area, deep story lines, stuff like that. It's a common enough comment, see e.g. MMO players complaining about "content drought".

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

 python

    
@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

 bash

    
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.

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.

Same thing in Norwegian with "tøy" (verktøy, fly, kjøretøy, plus fartøy for water-faring vessels) … and then tøy by itself means cloth or clothes (also available through klestøy)

Here in Norway the thirteenth yule-day is just the day we throw out the yule-tree and take down the decorations. We should start having cake after we're done cleaning!

Yes, always has been.

There's also no uppercase d in systemd, the word is entirely lowercase (but I'll still write it with an uppercase s at the start of sentences).

Yeah, the manpages for systemd are large but also informative. Most of us only use a small subset of the features—much like we never explored everything possible with separate init programs.

Having used Linux on the desktop for some two decades and worked as a Linux sysadmin for a good while I don't miss the init scripts. My impression is more that a certain cohort wants to pretend that service management is easy by ignoring large amounts of it. It's easy to write a bad init script that breaks when you really need it, or be out of your depth with more complex cases.

Not to mention the whole conformity by convention thing. Systemd unit files are descriptive and predictable by their nature. So-called init scripts didn't really have to be scripts, they just usually were, and their arguments and output and behaviour was also unenforced—there's nothing really stopping you from writing a compiled program that self-daemonizes and place the binary with the init scripts rather than in /bin. Ultimately people who make programs also have to be good at writing init programs with that setup.

So we'd have people doing dumb shit themselves and getting angry at others doing dumb shit. PHP was also pretty popular and full of dumb shit. Lots of "worse is better" to go around.

Ultimately it's more of the stuff covered in Bryan Cantrill's Platform as a reflection of values. Some of us value predictability and correctness, others feel it's a straitjacket. There's no way of pleasing everyone with the same platform.

And currently the people who want to distribute their own riced-out init programs in bash, perl, php, node.js and so on are SOL. (They can still use them on their own machines.)

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.

Too recent. Let Gore win back in 2000.

Or at the very least avoid car ownership and overuse:

When you use a 3500-pound car to transport your 150-pound self around, 96 percent of the weight of that clump of matter is the car. You’re moving 25 times more junk around than you need to, and thus using 25 times more energy to do it.

Imagine that you’re hungry for lunch, so you go to a restaurant. But you don’t just order yourself a blackened salmon salad for $15.00. You order twenty five salads for $375.00! Then, you eat one of them, and leave the other 24 blackened salmon salads, $360.00 worth of food, to get collected by the waiter and slopped unceremoniously into a big black garbage bag. All that fine wild-caught Alaskan Salmon, lovingly seasoned and grilled. All the fine crumbles of feta cheese, the mango salsa, diced green onion, shaved peppers, rich zingy dressing, and everything else the chef worked on for hours – plopped into the slimy garbage bag. This is exactly what you are doing, every time you drive!

Of course, a lot of people, especially in North America, don't really have an alternative, and they'll be financially and bodily worse off for it.

Yeah, like the -berg names (e.g. Stoltenberg), it's likely the family farm if you go far enough back. My family has a name that's an island and the settlement on it. Taking a profile picture next to the town sign that's also our last name is pretty common (for a name of a few hundred people).