remiliascarlet has quit [Remote host closed the connection]
remiliascarlet has joined #crux-musl
farkuhar has joined #crux-musl
<farkuhar>
The standalone /etc/rc.functions *does* respect the principle "separate data from code", moreso than incorporating the new colour functionality into rc.conf itself. If we propose to extract the user-editable network settings from /etc/rc.d/{net,wpa_supplicant} and put them in a purely-declarative file like rc.conf, then for consistency's sake, we cannot encumber rc.conf with the new colour functions too.
<farkuhar>
As for a more POSIX alternative to the bashism SERVICES=(lo net crond), I was just reading the NetBSD man-page rcorder(8), which parses the header of each rc.d startup script and sorts them by dependencies. NetBSD users don't need to orchestrate the startup sequence by hand; they just toggle a YES/NO variable for each service, and rcorder(8) figures out the right way to start them.
<farkuhar>
Now SiFuh_ might object that rc.functions meets the definition of "junk file", at least for those users who disable the colour feature. But those lines of code would have to appear somewhere, to satisfy the users who enable the colours, and I'd rather see them in a separate file than sprinkled throughout the /etc/rc{,.multi,.single,.shutdown} scripts (or cluttering /etc/rc.conf where an "UPGRADE NO" rule would block the rollout of subsequent fixes).
<farkuhar>
Hmm, NetBSD's /sbin/rcorder is a dynamically-linked binary, not a shell script. That shouldn't be an obstacle to porting the feature to CRUX, as long as our C standard library is close enough to what they have on NetBSD.
<farkuhar>
OpenBSD admins don't touch /etc/rc.conf; they make their edits in /etc/rc.conf.local. Meanwhile NetBSD admins gladly edit /etc/rc.conf (for example https://0x0.st/84Mj.conf on the machine I'm joining from), leaving /etc/defaults/rc.conf untouched.
<farkuhar>
POSIX-compliant sh commands, purely-declarative config, and inline comments without any glaring typos (no "devcies" as appeared in the CRUX 3.7 /sbin/start_udev). Plus, NetBSD's rc.conf has a comprehensive man-page. What's not to like?
<farkuhar>
There is a precedent in the BSD world for something like beerman's /etc/rc.functions, namely, the /etc/rc.d/rc.subr in OpenBSD. But those subroutines are doing something useful, not decorating the terminal with eye candy using nested printf commands.
<farkuhar>
I would eventually like to see CRUX get a man-page for rc.conf, the same way that NetBSD and OpenBSD have. Most of the work is already done (in the Handbook), it just needs to be formatted as a man-page, and kept up-to-date as we decide what belongs there (e.g., network settings).
<SiFuh_>
I haven't tested it. I was just going an example of what it could be like
<SiFuh_>
get_colour_code() { could be in an rc.colour script and it would be useful for those who can't remember how to use colours with printf and could be a reference file for future scripts.
<SiFuh_>
farkuhar: I didn't run it through shellcheck
<farkuhar>
SiFuh_: Thanks for providing a proof-of-concept.
<SiFuh_>
printerror <- looks like print terror :-P
<farkuhar>
NetBSD's rc.conf has support for an amusingly-named Boolean variable, rc_fast_and_loose. The user is warned against setting it to YES, because of the implications of starting each service in the parent shell (the default is to start it in a subshell).
<SiFuh_>
So the rc will get 'jiggy with it' hahaha
<farkuhar>
OpenBSD's rc.subr has this awkward construction: [ X"${rc_bg}" = X"YES" ] || [ -z "$$" ] && break . If someone is speed-reading, they might forget about the short-circuiting behaviour of ||, and erroneously conclude that `break` will be triggered by setting rc_bg=YES.
<SiFuh_>
Heh
<SiFuh_>
It's also written for ksh right?
<SiFuh_>
7 # Turn off Strict Bourne shell.
<SiFuh_>
8 set +o sh
<farkuhar>
I prefer the way Perl does ternary conditionals, actually. None of this overloading of && and ||.
<SiFuh_>
What is the url todownload the rc archive for crux 3.8?
<farkuhar>
I'd suggest `git clone https://git.crux.nu/tools/rc.git`, and that way you have the entire history in your local copy.
<SiFuh_>
rc.colours or rc.functions could be renamed to ansi.colours and be used like a universal file for other scripts the user might write
<farkuhar>
As zorz reminded us, they used to deploy the rc scripts directly through the ports tree, rather than putting a tarball URL in the rc Pkgfile.
<farkuhar>
Deployment of rc scripts via the ports tree does open up the possibility that some changes were inserted quietly, without leaving a trace in the tools/rc repo. For a complete picture of the historical changes, you'd need to git-clone the ports/core repo too.
<SiFuh_>
COLOR="bold red" # Examples are located in /etc/ansi.colors
<SiFuh_>
Suppose I should use the US spelling of color
<farkuhar>
SiFuh_: heh, https://dpaste.com/54BEPSAMW.txt represents a lot of research. Did you look up all those codes and type them in by hand?
<SiFuh_>
I went to ChatGPT and copied what I had written and said this "I would like EVERY Possible ANSI code because it is taken to long to type" Hehehe
<SiFuh_>
Also there should be a failsafe written into rc that checks if the file exists, if not, then it will change USE_COLOUR=false
<farkuhar>
Noted. Now you've got me curious why beerman went with the US spelling of color.
<SiFuh_>
farkuhar: probably US keyboard is default.
<farkuhar>
Ah, the default keyboard layout. That reminds me of the erik_ who recently joined #crux and asked for the nodeadkeys variant of a Swedish keyboard layout.
<SiFuh_>
And yes I am mounting /proc1 to force and error.
<SiFuh_>
And even though I am loading rc.conf, I am overriding it in the TEST.sh script as well. And I have a couple of echo commands for testing what the script is doing.
<farkuhar>
SiFuh_: So the colours are working for you now, although they weren't working before? It's weird that both ppetrov^ and I could see colours with beerman's code, but you had to write your own script before the colours would appear. Did you change anything in your kernel config, or the setting for TERM?
<farkuhar>
I remember struggling to get colours working in lynx, on a shared Unix machine at university. Playing around with different values of TERM didn't help. I eventually had to compile my own copy of lynx (against the slang libraries) and install it under $HOME, before the colours would work.
<SiFuh_>
farkuhar: Yes they are working. Also, this will need to be written this way https://dpaste.com/ANM9K7WYE
<SiFuh_>
SHouldn't these two lines have exit 1 to stop a 'catostrophy'?
<farkuhar>
Regarding https://dpaste.com/ANM9K7WYE do we really need to repeat ${COLOR_CODE} and ${RESET} on every line? I got it to work using a here-doc sandwiched between one ${COLOR_CODE} at the beginning, and one ${RESET} at the end.
<SiFuh_>
Well actually you don't but if you decided to use underline or invert the background then you should see what I mean. I never tested it.
<SiFuh_>
I just tested it with inverse and it looks fine the way you said.
<SiFuh_>
farkuhar: rc.single is calling for rc.functions. But I don't see any colour in this at all
<SiFuh_>
farkuhar: Okay, I think I am done.
<SiFuh_>
I have no system to test it on by the way
<SiFuh_>
Feel free to fix anything broken. Like missing ' or " or ; or extra new lines that shouldn't exist and so on.
<SiFuh_>
Also the tabs and spaces are fucked so it needs to be formatted how CRUX wants it.
<dlcusa>
You guys are demonstrating how the CRUX color enhancement should have been developed, an open process undertaken by developers who really care about the result properly fitting into the distro. Applause!
<SiFuh_>
dlcusa: ell I told beerman to fix it and he hated that I pointed out the code was bad and told me to fix it. I said I would not. I would you and if you refuse then eventually I will write it. Then you guys can review it.
<SiFuh_>
dlcusa: farkuhar: Also I modified the LVM to exit on error just in case something catostrophic happens. Although it can be easily removed from the script.
<SiFuh_>
dlcusa: Still don't know if it works though. I set it up as UNTESTED on my repo because it won't run on OpenBSD
<dlcusa>
But this open dialog is available for those coming in later for whom the man pages don't tell enough of the story.
<SiFuh_>
dlcusa: also a new variable in rc.conf so you can go to the ansi.colors file and select any in the list. Like COLORS="bold inverse green"
<SiFuh_>
dlcusa: I put a comment line in rc.conf COLOR="bold red" # Examples are located in /etc/ansi.colors
<SiFuh_>
farkuhar: Oh and if you don't mind run it through shellcheck. I didn't
<SiFuh_>
farkuhar: You may need to put a "$1" at the end of line 39 because line 84 and 88 will use it. The rest don't need "$1" but it should be ignored by the most part.
<SiFuh_>
Or could just remove the error message for, "Failed to scan LVM volume groups" "Failed to activate LVM volume groups" I just added that in to notify that it was failing.
zorz_ has joined #crux-musl
<SiFuh_>
farkuhar: Couple of small issues with shellcheck.
<farkuhar>
Now that we have a failsafe to prevent any attempts to source nonexistent files like ansi.colours and rc.functions, I suggest creating a separate port in the opt repo for the startup eye candy. That way it's not tied to the core/rc port, and the core repo can remain uncluttered by (what some users might consider) junk.
<farkuhar>
In a similar vein, rc.fix can be packaged in the xorg repo, rather than cluttering the core repo with fixes that don't apply to users running a headless host (or otherwise eschewing X11).
<SiFuh_>
Yeah and rc.fix should have it's own port too for those who don't use Xorg. But anyway. here is a thought. ansi.colors file can be a handy utillity. It is now self-contained, quite readable, and easy to source into any custom scripts anyone wants to make. The function get_color_code can easily be wrapped into their scripts.
<SiFuh_>
farkuhar: I got rid of rc.functions. It was kind an irregular name
<farkuhar>
Noted. Well, I've downloaded the latest tarball, so I can give it a try on my CRUX-MUSL laptop. Wish me luck!
<SiFuh_>
farkuhar: Just use my patch. I cleaned it up and used shellcheck
<SiFuh_>
The two archives are already deleted because there were some small issues that I missed.
<SiFuh_>
farkuhar: Also there may be some stray \n in there that shouldn't be on specific lines. Hopefully, I didn't miss any.
<farkuhar>
SiFuh_: The bash construct ${LANG:=C.UTF-8} has the side-effect of setting LANG to C.UTF-8 if the user hasn't defined it yet. Similarly for ${BLANKTIME:=15}. Use those constructs the first time you test for nonempty variable, and then a subsequent line like `export LANG` will do the right thing, no need to test again for nonempty variable.
<SiFuh_>
farkuhar: Noted, but that isn't my code.
<farkuhar>
SiFuh_: Okay, I was just looking for additional ways to clean it up before submitting a Gitea pull request.
<SiFuh_>
Good. I saw somethings I didn't like anyway. Also as much as I like those one line commands. Sometimes it just makes more sense to write the statement out in human readable form like I did with LVM
zorz_ has quit [Quit: leaving]
<SiFuh_>
farkuhar: I just pasted the patch in ChatGPT. Some long winded response from it. But this line caused me to laugh "You clarified error handling, especially around mount and fsck — the old code had deeply nested printf "$(BOLD "$(RED)")" insanity."
<SiFuh_>
I think ChatGPT sucks at code. But even it seems to notice how shit it was