6 ms·

Improvements are always nice but portability matters, so depending on new features isn't possible until it could safely be assumed to be ubiquitous (cough, not

Improvements are always nice but portability matters, so depending on new features isn't possible until it could safely be assumed to be ubiquitous (cough, not you Apple). Then there's the part where building anything of any significant complexity is not probably a good idea in a shell script.

chasil 4y ago
If portability is your primary concern, then you want a POSIX shell, or at least to ensure that your bash is always in POSIX mode. There are lots of behavior differences when bash's POSIX mode is set. Debian brought the Almquist shell in as /bin/sh, and is maintaining it with strict compliance to POSIX. This displaces bash as the system shell, but bash is still assigned as the interactive shell. http://gondor.apana.org.au/~herbert/dash/ http://gondor.apana.org.au/~herbert/dash/ This is an older standard for the behavior of the POSIX shell. There are many common shell features that are not here (arrays, networking, coprocesses, fancy substitution, and much more). Doing without them increases portability. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
- Ferret7446 4y ago
  >There are lots of behavior differences when bash's POSIX mode is set. AFAIU correct POSIX scripts will behave correctly with Bash POSIX mode. Incorrect POSIX scripts will not behave incorrectly with Bash POSIX mode as one might expect with a more faithful shell implementation. IMO Bash POSIX mode is not a problem for running scripts, although you should test your scripts using a strictly shell implementation if you will then distribute those scripts to other users/platforms.
- rwmj 4y ago
  In my view Debian boiled an ocean for no discernable gain and caused a lot of trouble for everyone in the process. Fedora is using bash and I hope we continue rejecting the mistake Debian made.
  - chasil 4y ago
    Debian dash is useful to keep my scripts honest. Busybox actually takes dash, and then sprinkles a few bash/korn features back onto it (notibly, not arrays). If you want a lot of people to use your scripts, getting them working in dash can help a great deal. The POSIX mode in bash exists because bash itself predates POSIX by nearly a decade.
    - rwmj 4y ago
      What does "keep my scripts honest" even mean? Just use bash and don't make everyone else boil your ocean. It's like saying you'll never use any Linux feature except those strictly defined by POSIX.1. Why would you do that?
      - chasil 4y ago
        Android uses mksh. If I write a script that uses read -p to present a prompt, it will fail on Android because it means coprocess on mksh. The fundamental reality is that GPL does not run on iOS or Android (in userland). If you want to run scripts on those platforms (and they are ENORMOUS), then you cannot use bashisms. Full stop.
    - kazinator 4y ago
      Note: BusyBox has two shell implementations in it, selected at compile time.
  - malkarouri 4y ago
    Are you building scripts for the Debian distro? Given that they already include bash and actually support it for interactive use, what would be the issue for you scripting using bash? I am sure that the experience of moving to dash wasn't fun at all. But users in general are not affected that much as far as I understand.
    - rwmj 4y ago
      I'm maintaining a bunch of core Linux packages which have had to make many adjustments over years for dealing with this Debian nonsense. I can see no justification for it since Fedora is using bash just fine and doesn't have to deal with this.
BiteCode_dev 4y ago
Portability for shell scripts is over rated in 2022. If your shell scripts are small, it's easy to write several versions of them. It they are long, you should use something else than shell scripts for your program, like python. Worse case scenario, provision the same interpretter everywhere, vendor it, or use a compiled language. There are some edge cases where portability makes sense (e.g: you are scripting for an heterogeneous parc of routers), but they are niche usages most companies don't care about.
- mburee 4y ago
  Because pulling in a huge python installation on small/embedded systems is fun, just because some people are unable to keep their scripts POSIX compliant
  - ms4720 4y ago
    Tcl, lua, or a lisp/scheme work well here
    - chasil 4y ago
      The nice thing is that many, many shells implement POSIX, so there is enormous portability. Busybox bundles the Almquist shell, and there is a Windows port available. This is the easiest and least intrusive way to run shell scripts on Windows. Busybox advertises that it bundles bash, but this is not true - it's Almquist with some added bashisms. It also bundles their own awk implementation, but not Tcl/lua/lisp/scheme.
  - kaba0 4y ago
    It’s not the compatibility which is the problem, but the 3 bugs/line that bash causes.
    - Alupis 4y ago
      If you cannot take the time to learn the language, what makes you so confident your python doesn't also have 3 bugs per line as well?
harry8 4y ago
Serious question, why should I care about portability to Apple in shell scripts? Why not make all your shell scripts #!/bin/bash and anything where that doesn't work is trying to be a second class citizen[1] in unix and so maybe let them? Or tell users to install Bash - which they can probably do if they're using shell scripts..? [1] Or maybe deliberately trying to break portability by market power abuse. I know I don't need tell anybody here that Apple is not their friend, merely a supplier who will maximize their revenue at your expense when it suits them.
- chasil 4y ago
  A few "gotchas:" I will commonly "alias p=printf" in my shell scripts. This is fine in Almquist and bash when called as /bin/sh, but if called as /bin/bash it fails, because bash only honors aliases in POSIX mode. In bash, reading with a prompt can be done with "read -p prompt var" but this fails in Korn because it's used for coprocesses. This means that your shell script will not run on Android, because mksh is the system shell. I could probably think of a few more with some effort, and especially a check of the man pages. p.s. I didn't downvote you.
  - joombaga 4y ago
    > bash only honors aliases in POSIX mode. Aliases certainly _work_ in bash (even when not in POSIX mode. What do you mean by "honors"?
    - chasil 4y ago
      Bash will not expand aliases within a shell script unless it is in POSIX mode. When not in POSIX mode, aliases are only expanded for interactive use. $ echo '#!/bin/sh \n alias p=printf \n p %s\\\\n "hello world!"' > ok.sh $ chmod 755 ok.sh $ ./ok.sh hello world! $ echo '#!/bin/bash \n alias p=printf \n p %s\\\\n "hello world!"' > nope.sh $ chmod 755 nope.sh $ ./nope.sh ./nope.sh: line 3: p: command not found
- andrewmcwatters 4y ago
  You should care about POSIX Shell Command Language compatibility because targeting anything above that will eventually require you to do more, not less, work. If you haven't run into this, you just haven't written enough for the shell yet. Once you run into it, you'll not want to write anything specifically for Bash or Zsh anymore unless you know beyond a shadow of a doubt that it will never be run in any other shell.
gogoyubari 4y ago
There are circumstances in which portability is not required. People have been writing bash before Apple picked it up and people keep writing bash despite Apple getting sent to GNUlag by GPLv3.
frou_dh 4y ago
Shared shell-scripts are only one side of the coin. The other is interactive use (incl. one's .bash_profile etc), where it doesn't matter what anyone else's system does or doesn't have installed.
rwmj 4y ago
For several projects, we simply define bash as a required dependency. All the bash scripts use "#!/usr/bin/env bash". Not had any issues with portability between versions of bash, and basically every platform we care about has bash at least as an alternative if not the default.
superkuh 4y ago
It's okay. Portability depends on the behavior of the developers on average, not the rate of new features added to a language. Bash developers are generally conservative and not going to be using the newest backwards incompatible features for at least a decade. Whereas, say, Rust dev demographics are more bleeding edge types and when they get new features they use them immediately. That's why bash scripts can be interpreted on any OS from 1995 to now and Rust can only be compiled on an OS which has updated it's rustc in the last 3 months. Gotta hand it to Bash devs. They do a good job.
- chungy 4y ago
  > That's why bash scripts can be interpreted on any OS from 1995 to now and Rust can only be compiled on an OS which has updated it's rustc in the last 3 months. You can get the same effect by trying to run scripts with bash 5.x features on a version of bash from 1995. Rust code since 1.0 has the same level of backwards compatibility that bash does.
  - superkuh 4y ago
    >Rust code since 1.0 has the same level of backwards compatibility that bash does. That's true and exactly what I said. It's the rust developer demographic that lacks the consideration to write backwards compatible code.
    - chungy 4y ago
      I'm not sure the message is being conveyed properly -- looking up the GNU archive, it seems Bash 1.14 was the current release in 1995. Are people still making sure their scripts are compatible in Bash 1.14? Surely there's a subset of scripts that happen to work, but with numerous features that have been added since, there are plenty of scripts that won't. Backwards compatibility isn't really about whether you can run code on _old versions_, but if you can run _old code_ on new versions. Scripts that were written with Bash 1.14 should work today (barring all the other external dependencies they may have...), but scripts that are written today won't necessarily work on 1.14. That's the same as the Rust analogy: code written with Rust 1.0 should compile and run today, but code written today won't necessarily work on Rust 1.0 (albeit, there must be a subset of new code that would happen to work).

chasil 4y ago

If portability is your primary concern, then you want a POSIX shell, or at least to ensure that your bash is always in POSIX mode. There are lots of behavior differences when bash's POSIX mode is set. Debian brought the Almquist shell in as /bin/sh, and is maintaining it with strict compliance to POSIX. This displaces bash as the system shell, but bash is still assigned as the interactive shell. http://gondor.apana.org.au/~herbert/dash/ http://gondor.apana.org.au/~herbert/dash/ This is an older standard for the behavior of the POSIX shell. There are many common shell features that are not here (arrays, networking, coprocesses, fancy substitution, and much more). Doing without them increases portability. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

Ferret7446 4y ago
>There are lots of behavior differences when bash's POSIX mode is set. AFAIU correct POSIX scripts will behave correctly with Bash POSIX mode. Incorrect POSIX scripts will not behave incorrectly with Bash POSIX mode as one might expect with a more faithful shell implementation. IMO Bash POSIX mode is not a problem for running scripts, although you should test your scripts using a strictly shell implementation if you will then distribute those scripts to other users/platforms.
rwmj 4y ago
In my view Debian boiled an ocean for no discernable gain and caused a lot of trouble for everyone in the process. Fedora is using bash and I hope we continue rejecting the mistake Debian made.
- chasil 4y ago
  Debian dash is useful to keep my scripts honest. Busybox actually takes dash, and then sprinkles a few bash/korn features back onto it (notibly, not arrays). If you want a lot of people to use your scripts, getting them working in dash can help a great deal. The POSIX mode in bash exists because bash itself predates POSIX by nearly a decade.
  - rwmj 4y ago
    What does "keep my scripts honest" even mean? Just use bash and don't make everyone else boil your ocean. It's like saying you'll never use any Linux feature except those strictly defined by POSIX.1. Why would you do that?
    - chasil 4y ago
      Android uses mksh. If I write a script that uses read -p to present a prompt, it will fail on Android because it means coprocess on mksh. The fundamental reality is that GPL does not run on iOS or Android (in userland). If you want to run scripts on those platforms (and they are ENORMOUS), then you cannot use bashisms. Full stop.
  - kazinator 4y ago
    Note: BusyBox has two shell implementations in it, selected at compile time.
- malkarouri 4y ago
  Are you building scripts for the Debian distro? Given that they already include bash and actually support it for interactive use, what would be the issue for you scripting using bash? I am sure that the experience of moving to dash wasn't fun at all. But users in general are not affected that much as far as I understand.
  - rwmj 4y ago
    I'm maintaining a bunch of core Linux packages which have had to make many adjustments over years for dealing with this Debian nonsense. I can see no justification for it since Fedora is using bash just fine and doesn't have to deal with this.

BiteCode_dev 4y ago

Portability for shell scripts is over rated in 2022. If your shell scripts are small, it's easy to write several versions of them. It they are long, you should use something else than shell scripts for your program, like python. Worse case scenario, provision the same interpretter everywhere, vendor it, or use a compiled language. There are some edge cases where portability makes sense (e.g: you are scripting for an heterogeneous parc of routers), but they are niche usages most companies don't care about.

mburee 4y ago
Because pulling in a huge python installation on small/embedded systems is fun, just because some people are unable to keep their scripts POSIX compliant
- ms4720 4y ago
  Tcl, lua, or a lisp/scheme work well here
  - chasil 4y ago
    The nice thing is that many, many shells implement POSIX, so there is enormous portability. Busybox bundles the Almquist shell, and there is a Windows port available. This is the easiest and least intrusive way to run shell scripts on Windows. Busybox advertises that it bundles bash, but this is not true - it's Almquist with some added bashisms. It also bundles their own awk implementation, but not Tcl/lua/lisp/scheme.
- kaba0 4y ago
  It’s not the compatibility which is the problem, but the 3 bugs/line that bash causes.
  - Alupis 4y ago
    If you cannot take the time to learn the language, what makes you so confident your python doesn't also have 3 bugs per line as well?

harry8 4y ago

Serious question, why should I care about portability to Apple in shell scripts? Why not make all your shell scripts #!/bin/bash and anything where that doesn't work is trying to be a second class citizen[1] in unix and so maybe let them? Or tell users to install Bash - which they can probably do if they're using shell scripts..? [1] Or maybe deliberately trying to break portability by market power abuse. I know I don't need tell anybody here that Apple is not their friend, merely a supplier who will maximize their revenue at your expense when it suits them.

chasil 4y ago
A few "gotchas:" I will commonly "alias p=printf" in my shell scripts. This is fine in Almquist and bash when called as /bin/sh, but if called as /bin/bash it fails, because bash only honors aliases in POSIX mode. In bash, reading with a prompt can be done with "read -p prompt var" but this fails in Korn because it's used for coprocesses. This means that your shell script will not run on Android, because mksh is the system shell. I could probably think of a few more with some effort, and especially a check of the man pages. p.s. I didn't downvote you.
- joombaga 4y ago
  > bash only honors aliases in POSIX mode. Aliases certainly _work_ in bash (even when not in POSIX mode. What do you mean by "honors"?
  - chasil 4y ago
    Bash will not expand aliases within a shell script unless it is in POSIX mode. When not in POSIX mode, aliases are only expanded for interactive use. $ echo '#!/bin/sh \n alias p=printf \n p %s\\\\n "hello world!"' > ok.sh $ chmod 755 ok.sh $ ./ok.sh hello world! $ echo '#!/bin/bash \n alias p=printf \n p %s\\\\n "hello world!"' > nope.sh $ chmod 755 nope.sh $ ./nope.sh ./nope.sh: line 3: p: command not found
andrewmcwatters 4y ago
You should care about POSIX Shell Command Language compatibility because targeting anything above that will eventually require you to do more, not less, work. If you haven't run into this, you just haven't written enough for the shell yet. Once you run into it, you'll not want to write anything specifically for Bash or Zsh anymore unless you know beyond a shadow of a doubt that it will never be run in any other shell.

gogoyubari 4y ago

There are circumstances in which portability is not required. People have been writing bash before Apple picked it up and people keep writing bash despite Apple getting sent to GNUlag by GPLv3.

frou_dh 4y ago

Shared shell-scripts are only one side of the coin. The other is interactive use (incl. one's .bash_profile etc), where it doesn't matter what anyone else's system does or doesn't have installed.

rwmj 4y ago

For several projects, we simply define bash as a required dependency. All the bash scripts use "#!/usr/bin/env bash". Not had any issues with portability between versions of bash, and basically every platform we care about has bash at least as an alternative if not the default.

superkuh 4y ago

It's okay. Portability depends on the behavior of the developers on average, not the rate of new features added to a language. Bash developers are generally conservative and not going to be using the newest backwards incompatible features for at least a decade. Whereas, say, Rust dev demographics are more bleeding edge types and when they get new features they use them immediately. That's why bash scripts can be interpreted on any OS from 1995 to now and Rust can only be compiled on an OS which has updated it's rustc in the last 3 months. Gotta hand it to Bash devs. They do a good job.

chungy 4y ago
> That's why bash scripts can be interpreted on any OS from 1995 to now and Rust can only be compiled on an OS which has updated it's rustc in the last 3 months. You can get the same effect by trying to run scripts with bash 5.x features on a version of bash from 1995. Rust code since 1.0 has the same level of backwards compatibility that bash does.
- superkuh 4y ago
  >Rust code since 1.0 has the same level of backwards compatibility that bash does. That's true and exactly what I said. It's the rust developer demographic that lacks the consideration to write backwards compatible code.
  - chungy 4y ago
    I'm not sure the message is being conveyed properly -- looking up the GNU archive, it seems Bash 1.14 was the current release in 1995. Are people still making sure their scripts are compatible in Bash 1.14? Surely there's a subset of scripts that happen to work, but with numerous features that have been added since, there are plenty of scripts that won't. Backwards compatibility isn't really about whether you can run code on _old versions_, but if you can run _old code_ on new versions. Scripts that were written with Bash 1.14 should work today (barring all the other external dependencies they may have...), but scripts that are written today won't necessarily work on 1.14. That's the same as the Rust analogy: code written with Rust 1.0 should compile and run today, but code written today won't necessarily work on Rust 1.0 (albeit, there must be a subset of new code that would happen to work).