@kline@mastodon.sdf.org"If '$arch' is empty, the `rsync` invocation to upload the packages for the current repo targets the wrong directory, resulting in the repositories for all other architectures to be removed."
bash reaps the souls of yet another ops team following an outage entirely prevented in literally any other language.
https://gitlab.alpinelinux.org/alpine/aports/-/commit/26fa920b8980f36bbd12dd503a5533a1b577aeb7
@kline Or just… have your shell-based language use set -eu (plus dialect-specific extensions like pipefail) like literally every shell scripting guide recommends. If it breaks existing package scripts then those packages probably shouldn't have been published in the first place
@kline@mastodon.sdf.org@nytpu you shouldn't need to take positive action to prevent your language system from punishing you for simple mistakes.
My car doesn't explode if I stall it.
The fact that this keeps happening is evidence in itself that the available "solutions" aren't effective
@lanodan@queer.hacktivis.me
@lanodan @kline @wolf480pl @nytpu there are already shell languages that fix the pain points of POSIX shell but it’s not possible to force whole world to suddenly switch from #!/bin/sh to something else
People want something better but it’s not possible to make that jump unless you’re willing to switch default shell org or distro wide
@pj @kline @lanodan @nytpu default shell soesn't matter, all that matters is that it's installed everywhere and has a consistent path. If you have a one #!/usr/bin/perl script in a #!/bin/sh world thay would work fine.
Question is, do your scripts that mostly invoke other programs become more maintainable and less error-prone after you rewrite them in Perl
@wolf480pl @kline @lanodan @nytpu
It does matter, because it’s the lowest common denominator across unix, one with the easiest/shortest bootstrap path, one that’s a must to know for every linux admin.
Somehow Alpine does not use any other shell language like Perl or Python unless absolutely necessary (like current pkgs.a.o) but it has all of them. So why Alpine had this problem if it already has present solutions?
Question is, do your scripts that mostly invoke other programs become more maintainable and less error-prone after you rewrite them in Perl
I have no idea because I don’t use Perl, but for me where equivalent language would be e.g. PowerShell, it does and that’s because the choice of language prevents lots of footguns present in POSIX shell (or slightly less when using e.g. BASH). In other words, POSIX shell is terrible syntax wise, lacks many functionalities one would expect in a scripting language and is mostly a stuck in time tech that doesn’t evolve which means no improvements.
@lanodan@queer.hacktivis.meI do think a shell replacement should be more comparable to like lua in terms of bootstrap, but in no way does it needs to be present everywhere, it just needs to build on a POSIX system, then it's effectively a dependency.
After all people use buildsystems other than make(1) fine, so a different shell is entirely possible.
@lanodan@queer.hacktivis.me@pj @kline @nytpu @wolf480pl By the way if you actually check POSIX, #!/bin/sh isn't part of it, yet you could reasonably consider that systems without a POSIX-conforming shell at /bin/sh are broken. https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sh.html#tag_20_110_16
@lanodan@queer.hacktivis.meYou need a shell to glue abuild, mqtt, rsync, … together.
@wolf480pl @kline @lanodan @nytpu
- It’s not bash
- That person now needs to know Lua, and anyone else who supports Alpine infra (or this package) needs to know Lua
and like, only those who maintain those scripts are affected, so they should be free to pick any language they find most suitable?
This has never went well in Alpine, and only ended with dead, buggy software
@wolf480pl @kline @lanodan @nytpu
so they should be free to pick any language they find most suitable?
Which is why it’s written as shell script
@pj @kline @lanodan @nytpu
btw. has anyone looked at https://www.oilshell.org/ ?
Yes, but depends on what you are asking?
I've been vocal about Alpine and/or pain of POSIX shell scripts for very long time and quite often I butt myself into random conversations about shells because I'm researching all of them and what would be "perfect" solution to all the problems.
I'm into all shell projects that try to build something better and working on designing a language that will fit both shell and scripting usage but it's not something that will spawn out of nowhere and maybe I will have enough of anything required to live to build such thing.
If you want to checkout already existing projects then things like https://murex.rocks/ or https://elv.sh are somewhat what I would look up to.
There are, but like this is the thing I'm talking about, POSIX shell is the most common denominator, whole Alpine is built on shell scripts because it's the easiest to bootstrap to (and required anyway)
You're dissecting one shell script that's used in some specific way without the context that whole distro is built on shell scripts, and you recommend that "just use something better" but there isn't something better that satisfies the requirements.
I'm with you on that I would like to see shell gone, this is major part of why I departed from working on Alpine packages and minimised its usage only to server-like behaviour.
I think as it is right now, there is no well known language that is specifically designed for the things POSIX shell is good at (except maybe PowerShell but I don't think it can run on POSIX).
If someone was to make one, it would have to first gain popularity in a smaller niche - idk maybe as one of the languages to write CI jobs in for some specific CI system. But if it was sufficiently good and well known, it could find its way into distros eventually.
PowerShell Core (`pwsh`) runs on anything that can run .NET (Windows, Linux, macOS; no idea if BSD also but I'm guessing yes?) and how much I shill it and I'm inspired by PowerShell language (I find it's the best combination of POSIX shell-like syntax with generic programming language), it's definitely not the solution (to anything that isn't big scale mostly since it's heavy JIT engine and boostrapping this is hell).
(I should finally focus properly on creating design doc and documenting all issues/features and referencing all projects to cover the whole "we hate POSIX shell" problem)
> I think as it is right now, there is no well known language that is specifically designed for the things POSIX shell is good at
That is absolutely true, it's basically a tool that's not great at anything but because it can do all stuff (sometimes in a worst way possible) it just stuck.
@lanodan@queer.hacktivis.meWhich is why for me there's a huge difference between those and shells.
And then the problem is stuff like fish/zsh/… are at least as arcane as sh, and even if you'd have a simple one like rc(1) [en.wikipedia.org] it's going to be seen as annoying for just a ~50 lines script.
So it's the kind of thing that needs to be adopted elsewhere first, at least I don't see it culturally coming from Alpine infra first.
@lanodan @kline @wolf480pl @nytpu
Whenever I’m on Linux, I’m cursing that I don’t have PowerShell with me (servers and alike where I can’t use it) because it just seamlessly handles process execution while still giving you a whole .NET and working programming language but also due to that it’s not the fastest thing (some people don’t like that $profile loads in more than 1 second).
Problem with fish/zsh/etc. is often that they are shell first, and language second. While my goto default shell on Linux is fish, it’s only due to it requiring almost no configuration and being interactively friendly (tab/history completions or other functions/keybinds are chef kiss). As a scripting language, IMO, it’s only slightly better than POSIX (sane naming for keywords like if [....] end are godsend but it doing variables and arrays via set sucks).
@pj @kline @lanodan @nytpu
tbh I think an sh replacement doesn't need to be a good interactive shell - we have plenty of those.
And in that area, there's execline[1] and while it has some good primitives for manipulating process state, I don't think it'd be a good fit for more high-level uses of shell.
@lanodan@queer.hacktivis.me @lanodan@queer.hacktivis.meLike imagine having to deal with things like error handling in your throwaway oneliners.
@kline@mastodon.sdf.org@lanodan @nytpu if everyday you stub your toe on a step that's a bit too high, you can put up a sign saying "wonky step" or you can fix the stairs.
It's been a long time where we've put various signs, mitigations, linters, and we're still stumbling on a badly made step.
We need to fix/replace. Yes, it'll be hard work and a lot to do, but better now than in the future when there's even more that needs done.
Even though `set -e` is not a silver bullet it is more often than not closer to the behaviour someone wants.
@wolf480pl
Actually set -e does exactly what I think it does, thank you very much. Because I actually bothered to read the spec defining what it does instead of assuming it magically stops all errors (which is very difficult just because a shell is entirely external command invocations, and because it was bolted onto an existing language). I don't think it's necessarily fair to blame shell as a whole (which has a lot of other stuff to be blamed for) because Bash fucked up the shell dialect even more and makes set -e very difficult to reason about.
@wolf480pl
I mean, I can only pinky promise I didn't run it but echo "hi" will be run because the “error” from false is ignored since foo is not the last member of an and–or list, then “survived 1”. “foo failed” isn't printed because the last statement of foo didn't fail in that chain, and “survived 2” wasn't printed because foo was considered as failing in the second standalone invocation.
Yeah, I guess it is pretty weird semantics but it's still only like three rules, they just have unexpected and confusing implications.