Recent searches
Search options
Administered by:
"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
@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 @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.
I 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.
You 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)
For .NET you need to either use an existing binary build or you cross-compile, and somehow even with that it's a royal pain in the ass to just build.
And that's with GHC having a possible bootstrap path with the retro implementations that are nhc98 + hugs but as far as I know, nobody managed it, even Guix.
@pj @kline @nytpu @wolf480pl And in fact the bootstrap question with Alpine in that context is kind of fun, imagine for a moment if said script ended up removing all the *.apk, including from the builders and past releases.
You'd probably have to drop at least Rust, GHC, .NET, … for few days and good luck on binary compatibility.
@pj @wolf480pl @lanodan Powershell wouldn’t really be immune from this kind of string interpolation error like in that Alpine script
> 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.