I haven't spent the time to look those in the init scripts closely, when I do and if I find such examples I will be sure to let you know. Personally I am in favor of fixing shellcheck warnings because it results in making more resilient and easier to read scripts. Its also is good at catching silly mistakes and my favorite bonus is that when someone who is less informed looks at the scripts later and adopts solutions they don't unintentionally include potentially unsafe code. It was the least trivial issue I mentioned by far, $container being potentially unset and the if/else/fi mess which leads to increased technical debt I think are more serious issues.

My hypothesis is that most of those legacy test warnings that already exist in the init scripts are trivial and the main benefit of fixing them is "Best practice" and making it easier to find real issues in the shellcheck output.

1 members found this post helpful.

I hadn't realised you had worked on it previously

When I brought it up via email you didn't mention anything, so I thought I'd get a head start and get the work done - guess I should have waited!

Do you have any examples of your solution? Are you still hoping to find a better way of achieving the same results, and if so, do you know when that might be?

OK, I guess I'll grant you that some of the time cleanups like this aren't purely cosmetic. That's why I purged all usage of backticks such as `command` in favor of $(command). In that case we gained not only a better syntax, but the ability to nest shelling out. Something like $(command $(anothercommand)) works, but `command `anothercommand`` doesn't.

The complaints about the test options -a and -o don't hold the same kind of water. You have to try really hard to come up with a case where they don't do the expected thing. And you don't have to look hard at all to find cases where blindly replacing them with the so-called best practice of [ command ] && [ command ] || [ command ] fails to do the expected thing because unlike the native -a -o tests it doesn't follow what would be expected algebraically with AND OR logic. As noted in the link, && and || have equal precedence, but -a has higher precedence than -o (or at least that's how it's been implemented in 100% of the systems I have worked with). The article notes that you could run into problems with -a and -o if they operate upon options that start with - or contain !. Any good shell programmer will take that into consideration. So I'm not ready to hop on board with the idea that everything needs to be converted to use && and ||, or that it is better (or "best practice" as it were), and certainly not that it's more readable.

That's my two cents about test syntax, anyway.

5 members found this post helpful.

Heh, well I work on a lot of things that don't end up seeing the light of day (yet, anyway). That's really most of what I do lately. Hopefully some of it will be good enough, but I do think a better end result happens when the foundation is actually good enough to start building on rather than jumping in and trying to refine crap.

This script utilizes the test I had for in/not-in a container, and should work for any container type, not just lxc:
But even with that test, I found myself reluctant to merge all those container tests into the main set of init scripts. The better path forward seemed to be breaking out any code that you wouldn't want to be running in a container (such as the fsck stuff) into a separate init script so you could just have the simplified:
I'm still not sure that it's worth it, but perhaps it is. Syncing up the scripts shipped with lxc is worth doing, at least.

2 members found this post helpful.

Yes, but POSIX also says: My two cents on this topic.

Ah, you've hit a bit of a problem there

I considered this test myself, and was about to start using it when I discovered that recent versions of LXC don't have that parameter set to != 1 inside containers.

From my slackware.uk container (running in privileged mode on LXC from -current):
Breaking out the code into separate rc scripts is going to result in quite a few new rc scripts - that was something I was trying to avoid when I continued to base the work off of the .lxc scripts already created by Ponce and Chris Willing.

Heh, I believe it's worth it Syncing up the scripts for sure, but I definitely believe integrating the two sets of scripts is worthwhile too.
Just my 2p!

Does in that case still spit out "container=lxc"?

Another option could be probe once for container, "export container=yes/unset container" and put in the head of all unwanted init-scripts something like "[ -z "$container" ] && exit 0", and leave rc.S,rc.M... as is, just thinking out loud.

It does indeed still include the "container=lxc" string in recent versions of LXC - whereas the /proc/1/sched approach doesn't yield the non-1 output Pat's test relies on.

or find a way to just once test the container variable and refer / include / point to to the initscript(s) you want,
this would, as a side effect and for free, give space to alternative init scripts variants

The backticks was another thing I noticed, but I didn't realize you already cleaned them up.

Generally I can't fault your stance and agree with it in part. Personally I try to spend time cleaning up shellcheck warnings and similar in my own scripts, but I understand that the feeling of fulfillment can be largely placebo beyond making it easier to spot significant warnings when there are fewer trivial warnings. I recall examples of broken compiles in other programs where the trivial gcc warnings yelled so loudly it made it far more difficult to find the real errors where additional compiles with the warnings disabled were required...

That said there is one thing the posix spec mentions which might of been relevant here given $container could be unset or user set. Granted making sure $container is set is trivial. but it shows that its easy to reach undefined behavior without intending.
http://pubs.opengroup.org/onlinepubs...ties/test.html

Thanks for the heads up with this program. I'm already seeing some things I can change in some of my scripts.

For those curious, they have a website that supports copy/pasting code for a check or you can use the SlackBuild provided by Andrew Clemons (note, it has many haskell dependencies).

I couldn't use the werbsite it for EFI3M, too big, so I checked locally. The heuristic is not perfect so you have to exercise your critical mind, but it certainly helps. At least EFI3M runs on all Linux distributions on which I have tried it: Slackware and derivatives, Fedora, Debian, openSUSE, Arch Linux, Solus. Alas it wouldn't work on a *BSD or on Mac OS because it runs lsblk which needs a Linux kernel.

Not sure what the desired solution to use will be, but perhaps this little project can help with the container determination test(s):

http://people.redhat.com/rjones/virt-what/

Couple of notes:

1. The git link on that page doesn't work.

2. Although the virt-what thing is a shell script (that's done some of the tests described in this thread), there's a small program it makes.

While I suggested this app to TommyC while we were discussing this thread on IRC, I wasn't aware of it at the time of originally working on the auto-detection patch - wish I had been, as it would have saved me a bit of research into how to achieve it!

Still, since this uses the same test to detect LXC that I came up with, it's at least confirmation that the /proc/1/environ method is the way to go if Pat doesn't decide to add the full virt-what package to Slackware

Just a note with an updated location for the containerised rc scripts, as I've recently changed the layout of my git repos: Containerised Slackware rc files

I've been continuing to update the rc files with changes from -current - the repository should only ever be a couple of days behind any changes made in the development cycle.

Please let me know via a note here if anything appears to be brokem/missing in the scripts.

2 members found this post helpful.