5 ms·

This article complains that using the extended GNU features (--ignore-case, set -o pipefail etc) makes scripts less portable. Fair enough. What it doesn't expl

This article complains that using the extended GNU features (--ignore-case, set -o pipefail etc) makes scripts less portable. Fair enough. What it doesn't explain is why a Linux user should much care about portability. OpenBSD and FreeBSD are alive and well, but the number of users seems so small that they aren't a particular concern. Maybe you could argue that we "should" consider these OSes out of a sense of fairness, but where does that stop? Do I also need to consider something obscure like vxWorks? BusyBox (Alpine) is more interesting, but the changes there are so significant that a port will almost always be needed anyway. Are there other compelling reasons to care about the non-GNU ecosystem?

kqr 3y ago
Is your comment best read in Internet Explorer 6? ---- What I'm trying to say is that open standards (and the portability that comes with them) is not something that just happens on its own. It takes active maintenance, and part of that maintenance is opting to adhere to the standard even when it would be more convenient to use extensions available in the most popular systems. Will you personally suffer from liberally using Bashisms? Not in the first order. But if we encourage that sort of thinking as a rule, the standards become meaningless. I believe that would be a net negative change for the world, but there are many intelligent people who would disagree.
- dspillett 3y ago
  I don't disagree with you in the context of public scripts, but the vast majority of what I do with bash is local-only (where local is ${DayJob} and my own infrastructure/projects) so the fact that extensions to the standard make my work in those areas quicker to string together and easier to maintain afterwards means I'm happy to lock myself into bash. From my PoV it is generally portable anyway: almost everywhere I use a shell of that nature bash is present. The exceptions to this are things that need to run in small environments, like anything which may end up in initrd (where busybox us generally providing shell/script support). Though I do wish people would make sure they specify bash in the #!/bin/bash in scripts unless trying to stick to the standard, as using #!/bin/sh causes problems when extensions are used and something lighter than bash is the default script runner (i.e. dash in Debian, and again busybox commonly in small environments). Only use #!/bin/sh if you lnow you are making an effort to be compliant.
  - kqr 3y ago
    > I don't disagree with you in the context of public [things], but [...] extensions to the standard make my work in [private] areas [...] happy to lock myself into [a non-standard]. This is the best argument I know in favour of not standardising, and the danger is not the direct consequences, but rather than our expertise in the standard atrophies when we do most of our work outside of it, which means our public work suffers too. Also sometimes the private goes public and then who's gonna fund redesigning it in the standard? That rarely happens. > From my PoV it is generally portable anyway: almost everywhere I use a shell of that nature bash is present. Much like Internet Explorer 6, you mean.
    - dspillett 3y ago
      > Much like Internet Explorer 6, you mean. A key difference is that bash is not claiming to be standard where it is not. It implements the full standard as well as its own extensions. It does not do standard things wrong¹ in order for its extensions to work². I see posix-sh/bash more like javascript/typescript than good-browsers/internet-explorer. Which makes me wonder: is there a gnu/bash->posix/sh converter out there… -- [1] well, there are a few oddities, like == behaviour in test which can cause portability issues because the standard doesn't specify that and people might accidentally use it when trying to be as portable as possible, but this also affects sh so is a general environment issue not specifically a bash related one. Also that doesn't break standard portable behaviour. [2] or in the case of IE, doing standard things wrong, and its own extension wrong between versions too!
- pmarreck 3y ago
  > Is your comment best read in Internet Explorer 6? I actually feel triggered. That was such a nightmare period in my web-dev career (pretty much the entire 2000's), it pretty much singlehandedly pushed me to find backend work as much as humanly possible
chasil 3y ago
You will notice that the parent article mentions "dash." The dash shell is small and fast, but it does not allow any bash/korn language extensions beyond what was recorded in the POSIX.2 standard in the early 1990s. Linux users should care because the Debian/Ubuntu family use dash as the system shell, so this problem is very real as many have learned.
pjungwir 3y ago
I want to agree, but macOS is a big one. For example `sed -i` has bitten me before.
sundarurfriend 3y ago
I find the obsession with shell-script portability in contexts where it doesn't matter to be bizarre, but this particular argument is amusing: > the number of users seems so small that they aren't a particular concern. Maybe you could argue that we "should" consider these OSes out of a sense of fairness, but where does that stop? This is the same argument that many companies and products have made over the years (and still do at times) for ignoring Linux. To have a Linux user use that same argument against OSes with even smaller userbases is kind of amusing to see.
jonhohle 3y ago
`-o pipefail` isn’t a GNU extension or even a difference in user space programs, but specifically a bash option. The portability is between shells, not operating systems. It will work on bash, regardless of the underlying OS, but may or may not work on csh, ksh, fish, etc.
jmopp 3y ago
Mac's command-line tools are the BSD versions. I always get confused about the command-line arguments for `date` because they differ so much betwen platforms.

kqr 3y ago

Is your comment best read in Internet Explorer 6? ---- What I'm trying to say is that open standards (and the portability that comes with them) is not something that just happens on its own. It takes active maintenance, and part of that maintenance is opting to adhere to the standard even when it would be more convenient to use extensions available in the most popular systems. Will you personally suffer from liberally using Bashisms? Not in the first order. But if we encourage that sort of thinking as a rule, the standards become meaningless. I believe that would be a net negative change for the world, but there are many intelligent people who would disagree.

dspillett 3y ago
I don't disagree with you in the context of public scripts, but the vast majority of what I do with bash is local-only (where local is ${DayJob} and my own infrastructure/projects) so the fact that extensions to the standard make my work in those areas quicker to string together and easier to maintain afterwards means I'm happy to lock myself into bash. From my PoV it is generally portable anyway: almost everywhere I use a shell of that nature bash is present. The exceptions to this are things that need to run in small environments, like anything which may end up in initrd (where busybox us generally providing shell/script support). Though I do wish people would make sure they specify bash in the #!/bin/bash in scripts unless trying to stick to the standard, as using #!/bin/sh causes problems when extensions are used and something lighter than bash is the default script runner (i.e. dash in Debian, and again busybox commonly in small environments). Only use #!/bin/sh if you lnow you are making an effort to be compliant.
- kqr 3y ago
  > I don't disagree with you in the context of public [things], but [...] extensions to the standard make my work in [private] areas [...] happy to lock myself into [a non-standard]. This is the best argument I know in favour of not standardising, and the danger is not the direct consequences, but rather than our expertise in the standard atrophies when we do most of our work outside of it, which means our public work suffers too. Also sometimes the private goes public and then who's gonna fund redesigning it in the standard? That rarely happens. > From my PoV it is generally portable anyway: almost everywhere I use a shell of that nature bash is present. Much like Internet Explorer 6, you mean.
  - dspillett 3y ago
    > Much like Internet Explorer 6, you mean. A key difference is that bash is not claiming to be standard where it is not. It implements the full standard as well as its own extensions. It does not do standard things wrong¹ in order for its extensions to work². I see posix-sh/bash more like javascript/typescript than good-browsers/internet-explorer. Which makes me wonder: is there a gnu/bash->posix/sh converter out there… -- [1] well, there are a few oddities, like == behaviour in test which can cause portability issues because the standard doesn't specify that and people might accidentally use it when trying to be as portable as possible, but this also affects sh so is a general environment issue not specifically a bash related one. Also that doesn't break standard portable behaviour. [2] or in the case of IE, doing standard things wrong, and its own extension wrong between versions too!
pmarreck 3y ago
> Is your comment best read in Internet Explorer 6? I actually feel triggered. That was such a nightmare period in my web-dev career (pretty much the entire 2000's), it pretty much singlehandedly pushed me to find backend work as much as humanly possible

chasil 3y ago

You will notice that the parent article mentions "dash." The dash shell is small and fast, but it does not allow any bash/korn language extensions beyond what was recorded in the POSIX.2 standard in the early 1990s. Linux users should care because the Debian/Ubuntu family use dash as the system shell, so this problem is very real as many have learned.

pjungwir 3y ago

I want to agree, but macOS is a big one. For example `sed -i` has bitten me before.

sundarurfriend 3y ago

I find the obsession with shell-script portability in contexts where it doesn't matter to be bizarre, but this particular argument is amusing: > the number of users seems so small that they aren't a particular concern. Maybe you could argue that we "should" consider these OSes out of a sense of fairness, but where does that stop? This is the same argument that many companies and products have made over the years (and still do at times) for ignoring Linux. To have a Linux user use that same argument against OSes with even smaller userbases is kind of amusing to see.

jonhohle 3y ago

`-o pipefail` isn’t a GNU extension or even a difference in user space programs, but specifically a bash option. The portability is between shells, not operating systems. It will work on bash, regardless of the underlying OS, but may or may not work on csh, ksh, fish, etc.

jmopp 3y ago

Mac's command-line tools are the BSD versions. I always get confused about the command-line arguments for `date` because they differ so much betwen platforms.