New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OS detection is wrong #38

Closed
moviuro opened this Issue Jun 23, 2016 · 20 comments

Comments

Projects
None yet
3 participants
@moviuro

moviuro commented Jun 23, 2016

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

__os="Linux"
)

Suggestion: use uname(1) instead.

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

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?

Owner

kvz commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@moviuro

moviuro Jun 23, 2016

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) 😉

moviuro commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

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

?

Owner

kvz commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

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

Owner

kvz commented Jun 23, 2016

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

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

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.

Owner

kvz commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@moviuro

moviuro Jun 23, 2016

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)

moviuro commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

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?

Owner

kvz commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

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

Owner

kvz commented Jun 23, 2016

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 kvz referenced this issue Jun 23, 2016

Merged

Better OS detection #39

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

@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.

Owner

kvz commented Jun 23, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Jun 23, 2016

Collaborator

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...

Collaborator

zbeekman commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@moviuro

moviuro Jun 23, 2016

@kvz works for me 👍

moviuro commented Jun 23, 2016

@kvz works for me 👍

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

@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.

Owner

kvz commented Jun 23, 2016

@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 kvz closed this in #39 Jun 23, 2016

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

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)

Owner

kvz commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Jun 23, 2016

Collaborator

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... 😆 )

Collaborator

zbeekman commented Jun 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Jun 23, 2016

Collaborator

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.

Collaborator

zbeekman commented Jun 23, 2016

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 kvz reopened this Jun 23, 2016

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 23, 2016

Owner

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

so reopening this issue

Owner

kvz commented Jun 23, 2016

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

so reopening this issue

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 24, 2016

Owner

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

Owner

kvz commented Jun 24, 2016

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 kvz referenced this issue Jun 24, 2016

Merged

No more os detection #41

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 24, 2016

Owner

Up for review #41

Owner

kvz commented Jun 24, 2016

Up for review #41

@zbeekman

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Jun 24, 2016

Collaborator

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.

Collaborator

zbeekman commented Jun 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Jun 24, 2016

Collaborator

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

Collaborator

zbeekman commented Jun 24, 2016

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

@kvz kvz closed this in #41 Jun 24, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment