<jaeger>
I do see the problem in rc.single, though
<jaeger>
The quoted syntax is kinda unintuitive even if it does get the desired result
<jaeger>
And it's easy to break with more quoting
<jaeger>
For example:
<jaeger>
TEST=("wtf" "is this")
<jaeger>
for x in ${TEST[@]}; do echo "[$x]"; done
<jaeger>
[is]
<jaeger>
[wtf]
<jaeger>
[this]
<jaeger>
for x in "${TEST[@]}"; do echo "[$x]"; done
<jaeger>
[wtf]
<jaeger>
[is this]
<farkuhar>
jaeger: Sorry, I should have specified that commit "rc: 2.32 -> 2.33" was in the tools/rc repo. Also, try this minimal example to check the size of the resulting array: https://0x0.st/8H1y.sh
grunge has quit [Read error: Connection reset by peer]
grunge has joined #crux-devel
grunge has quit [Changing host]
grunge has joined #crux-devel
<farkuhar>
It does get the desired result when you start the for loop with the array unquoted, but with that syntax you might as well be expanding a multi-token string that has whitespace separating the services. In other words, you don't gain the one advantage that arrays offer: support for filenames in /etc/rc.d that might contain whitespace.
grunge has quit [Read error: Connection reset by peer]
grunge has joined #crux-devel
grunge has quit [Remote host closed the connection]
<r0ni>
maybe a mis-configuration on my side, but invoking a "pkgmk -is" within a port dir isn't ignoring sigs, seems any of the ignore options won't do it unless i turn off the opt in pkgmk.conf. this didn't act this way like six months ago
<jaeger>
Why did we add the quotes to the R_SERVICES references? It wasn't that way in 3.7
<beerman>
i'll need to look into it after work
<farkuhar>
As to why quotes were added? If R is an array with n elements, then "${R[@]}" expands to n separate double-quoted strings, allowing you to preserve any whitespace appearing in an array element. There's no canonical way to generalize this behaviour to "$s ${R[@]}", so bash falls back to expanding it as one long string enclosed in quotes.
<farkuhar>
So the only thing you gain by adding the quotes (which weren't present in 3.7) is support for the rare user who populates /etc/rc.d with a filename containing whitespace, and expects to be able to add it to the SERVICES array.
<farkuhar>
Now if we took a firmer stance on not supporting whitespace in rc script names, or user redefinitions of IFS, then the new quotes become superfluous. At that point we can reconsider whether bashisms need to be employed at all; the rc scripts could be rewritten for something smaller like dash. Two prototypes: https://0x0.st/8H9J.shhttps://0x0.st/8H9y.sh
<farkuhar>
As ukky reminds us, the niche that dash occupies (processing non-interactive shell scripts) allows it to run without as many linked-in libraries (readline or ncursesw), thereby preserving bootability in situations where an updated shared library might break bash.
<farkuhar>
In yesterday's exchange with ukky, I pointed out that bash wasn't always so bloated, and might even have been comparable in size to today's dash at the time of CRUX 2.*. The bash ChangeLog itself testifies to the accumulation of new array features over the years, yet the CRUX rc scripts continued using the restricted feature-set of bash 2.0.
<beerman>
farkuhar: before we forget it, will you move stuff in contrib 3.8 around?
<farkuhar>
beerman: sure, I'll rename my *mm ports in contrib 3.8 later today.
<beerman>
ok, perfect, thanks
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux-devel
<farkuhar>
beerman: glibmm and pangomm have now been renamed in contrib 3.8. Feel free to take those short names for their gtk4 counterparts. (And add to setup-helper the appropriate rename_packages commands.)
<beerman>
perfect, I'll try to get that done in a bit as well as get the rc fix in you proposed.
<beerman>
thanks!
<beerman>
jaeger: do you wanna do the change in iso.git for the next build?
<jaeger>
sure, I have a change or two to push anyway, I think
<jaeger>
Is the list glibmm -> glibmm-gtk3, pangomm -> pangomm-gtk3, glibmm-2.68 -> glibmm, and pangomm-2.48 -> pangomm? The latter 2 assume you're going to drop the -gtk4 suffix based on farkuhar's short name comment
<beerman>
This looks correct yeah, let me get in there
<beerman>
we could do one more for gtkmm4 -> gtkmm to be clean in that regard
<jaeger>
ok
<beerman>
just pushed
<beerman>
jaeger: quotes in rc were just lints reported by shellcheck but this one is an oversight, I'll add the fix for that too
<jaeger>
Ah, fair enough
<beerman>
rewriting it with dash in mind instead of bash sure could be nice, but nothing for tonight
<jaeger>
There's a typo in my libnghttp2 commit message but it's correct in the Makefile, heh
<farkuhar>
r0ni does raise a good point about the precedence assigned by pkgmk. Options are read in this order: 1 - command line, 2 - Pkgfile, 3 - pkgmk.conf (last one wins). Normally IGNORE_SIGNATURE is commented out in pkgmk.conf, but if r0ni uncommented it and set it to "no", then -is at the command line would have no effect.
<farkuhar>
At the moment I can't think of any Pkgfiles that try to override the IGNORE_* variables, but you can easily create one with IGNORE_SIGNATURE=no to test whether it nullifies the command-line option.
<farkuhar>
It reminds me of the Flyspray task "pkgmk sources Pkgfile before verifying signature", which always appeared at the top of the list, being the only task with the highest severity level. Some of the comments on that task pointed out the ability of a malicious port to redefine internal pkgmk functions, including check_signature().