OS detection is wrong

[moviuro]

You can't just assume __os="Linux" (

bash3boilerplate/main.sh

Line 29 in 1f2e184

__os="Linux"

)

Suggestion: use uname(1) instead.

[kvz]

Thanks for the feedback @moviuro! As replied on reddit, We're testing against the different platforms automatically via Travis CI and it seems we can get away without running any commands, which we felt was better. Are there clear disadvantages to the chosen route you feel?

[moviuro]

Yes, main.sh wouldn't run correctly on BSD systems, which are not Linux.

E.g.: Read the man pages of OpenBSD sed(1) and compare them with GNU sed(1) 😉

[kvz]

That makes sense. Ideally I'd like to try if we can keep using OSTYPE while also supporting BSD flavors. I read that FreeBSD could be supported via "${OSTYPE}" == "freebsd"*, would you happen to know about the other BSD variants? Perhaps a *"bsd"* could get us a long way already.

I think I'd like to dumb down the __os variable to main families, and avoid imposing onto the end user that they'd have to check for DragonFly, OpenBSD, NetBSD, etc. My reasoning is, if they're interested in those flavors, they are having more advanced checks anyway, such as running uname or checking ${OSTYPE} themselves. I could leave an explicit comment about that in the source and/or FAQ.

The __os variable is intended more for novice users who might want to bail out on BSD, switch to using brew for OSX, or check for a configuration or startup file in a family-specific place.

My proposal hence would be to dumb this down to:

• Linux
• BSD
• OSX
• Windows

for now (even though OSX might technically belong to the BSD family)

So how about something along the lines of:

if [[ "${OSTYPE:-}" == "linux"* ]]; then
  __os="Linux"
elif [[ "${OSTYPE:-}" == "darwin"* ]]; then
  __os="OSX"
elif [[ "${OSTYPE:-}" == "msys" ]]; then
  __os="Windows"
elif [[ "${OSTYPE:-}" == *"bsd"* ]]; then
  __os="BSD"
else
  __os="b3bp_unsupported"
fi

?

[kvz]

Seems like we won't be able to have automated tests for FreeBSD for a while unfortunately travis-ci/travis-ci#1818

[kvz]

E.g.: Read the man pages of OpenBSD sed(1) and compare them with GNU sed(1)

I've had my fair share of problems switching my workstation from ubuntu -> osx which also doesn't come with my beloved gnu sed :'(. We even have to do this sed dance to have something portable across those platforms: https://github.com/kvz/bash3boilerplate/blob/master/src/templater.sh#L41 while it might have been easier to not make any backups at all. vs doing it and then removing :)

It's just that b3bp didn't support (OSX-less) BSD before, but I'm happy to change that. I'm fairly confident it will run if b3bp runs on OSX.

[moviuro]

Sounds good. However, there are still differences between OpenBSD and FreeBSD (I wouldn't know for NetBSD as I haven't used it that much yet).

Here's another idea:

• __os could be specific (ArchLinux, Mint, Ubuntu, FreeBSD)
• A new variable __os_family could be more generic (BSD, GNU/Linux, Windows)

[kvz]

Yes. And of course there are plenty of differences between CentOS and Debian or instance. E.g. what package manager to use or the other things I mentioned like startup services. However, those even vary between Ubuntu releases (going from init.d -> upstart -> systemd). So you'd really need all the information, even the OS version if you're going to code around those parts. I'm not sure if b3bp should provide this as boilerplate or that this is a usecase specific enough that we should allow users to walk their own paths there. It might be hard to cover all the edge cases, increasing our boilerplate with 100 lines, and still missing a enough cases to not have a truly satisfactory os abstraction.

Back to your proposal, what would __os contain? Just OSTYPE?

[kvz]

For reference, if we want to introduce __os_family, it would probably be more correct if BSD where a subfamily under Unix https://en.wikipedia.org/wiki/Category:Operating_system_families

[kvz]

@moviuro You see how in trying to be correct and supporting all cases, we quickly become bloated and all about os detection, whereas our purpose is more generic. I made a proposal more inclined to the pragmatic side, keeping an eye on the compactness of b3bp, in #39. I think we should cherish this compactness. There are plenty of complete os detection libraries and guides online. For b3bp though I'm looking for something pragmatic that newcomers can apply while decreasing the likelihood of them hurting themselves, and without imposing a steep learning curve.

I hope you'll agree #39 is already an improvement over what we had, since I agree that defaulting to Linux was a bit ridiculous.

[zbeekman]

Another idea is just get rid of the __os magic variable... AFAICT, we don't need it anywhere, so the user could be left to deal with the OS detection if they require it...

[moviuro]

@kvz works for me 👍

[kvz]

@zbeekman I do use it myself in places though, mostly to formulate urls to download appropriate static packages. I'd like to keep this via #39 for now, unless you feel strongly about ditching. Then please feel free to re-open this thread to have a bit more of a discussion about it.

[kvz]

I guess, alternatively, we could decide to do a monster project for detecting OS the right way, and put that as a separate function in ./src (and remove it from main.sh indeed)

[zbeekman]

I'm of the opinion that it is beyond the scope of main.sh because client code will have a better understanding of the context in which it is running, and OS type/detection is beyond just pure Bash3... I feel like it's better to do it "right" or leave it to client code... but I'm more than happy to defer to your judgment.

At the end of the day, anyone who needs a really precise and accurate OS determination (because their code may run on tons of different systems) a) might not want a bash3-specific solution (they may only have sh, csh, etc.) b) probably has the experience and know how to code the OS detection themselves, c) can take a quick glance at what we provide (if anything) and determine if it fits their needs. So I'm more than happy to defer to your judgement. (With the caveat, that if you provide it, and it doesn't detect system xyz correctly, a user will probably come tell us about it... 😆 )

[zbeekman]

E.g.: Read the man pages of OpenBSD sed(1) and compare them with GNU sed(1) 😉

Yes this is very true... sed and friends can have very subtle annoying differences across OSes... I'm going to work to remove any reliance on sed and awk, etc.

[kvz]

As @zbeekman mentioned, we might want to add cygwin and such

so reopening this issue

[kvz]

Going over this thread again after a good night's sleep, @zbeekman's arguments resonate more than they did yesterday, I think I had a bit of a hard time killing this darling because I had a personal use for it, but that's a really bad reason to keep it in a project used by many. I'll work around this on my end, let's remove it. Sorry for changing my mind like this in a day, I realize it must be very confusing to follow along. Will propose a new PR

[kvz]

Up for review #41

[zbeekman]

PR LGTM. If it just comes down to parsing $OSTYPE I don't think we're adding much value.

I think it might be wise to add a comment to main.sh about the existence of $OSTYPE in Bash, which I personally was unaware of until b3bp and how it may be useful.

[zbeekman]

L12 handles making the user aware of OSTYPE, I say 🚢 it 😄