6 ms·

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'

by 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.
- dolni 4y ago
  Nearly all of the shell scripts ever written don't need to run on Linux, and BSD, and Mac, and/or whatever esoteric Unixes that are still out there. If you are writing a shell script with the intention of running in many places, fine. But if you do that, the POSIX compatibility will be the least of your worries.
chungy 4y ago
> Why not make all your shell scripts #!/bin/bash Because it's not always installed there. See, for example, FreeBSD where bash typically lives in /usr/local/bin/bash. Or in the Linux world, Nix and Guix. Use "#!/usr/bin/env bash" to account for all these possibilities.
- Ferret7446 4y ago
  If we're going to be pedantic, env doesn't have to be installed at /usr/bin/env either. See https://www.felesatra.moe/blog/2021/07/03/portable-bash-shebang https://www.felesatra.moe/blog/2021/07/03/portable-bash-sheb...
- tpoacher 4y ago
  i cant remember where I saw it now, or what the main argument was, but I remember reading a rather authoritative article recommending against the env approach, and recommending people stick to #!/bin/bash regardless of the above, otherwise valid point. Dunno if anyone here with a better memory remembers the article to link here ...
  - asicsp 4y ago
    Perhaps these? * https://unix.stackexchange.com/a/29620 https://unix.stackexchange.com/a/29620 * https://stackoverflow.com/q/21612980 https://stackoverflow.com/q/21612980
coldpie 4y ago
Serious answer, because I have users/customers who I care about that use that platform, and sometimes I use it myself. A world built on absolutes falls to pieces really quickly.
yjftsjthsd-h 4y ago
> Serious question, why should I care about portability to Apple in shell scripts? It depends on your target audience, of course, but Darwin is one of the major current OSs and wanting to support it is reasonable. > 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..? Well, for starters AFAIK /bin/bash on Darwin will give you bash 3.2, which is a bit old and feature-poor. Of course you can (and perhaps even should) simply install a new version but then it won't be at /bin/bash, it'll be under /usr/local or /opt or whatever. And BASH isn't POSIX so I'd personally argue that trying to force it makes your stuff the "second class citizen in unix". Honestly I'm not sure what position you're trying to argue. "Ignore the second biggest desktop OS because they don't ship the latest version of the non-standard scripting language I like"?
- gogoyubari 4y ago
  >"Ignore the second biggest desktop OS because they don't ship the latest version of the non-standard scripting language I like"? There's nothing wrong with that position. Bash is not a "non-standard scripting language people like", it is the de-facto standard on Linux (heck, it was the first program Torvalds ever run on Linux) and the most widespread implementation of POSIX shell in the world. If Apple chosed tivoization[1] over freedom, so I can choose the #!/bin/bash shebang. [1] https://en.m.wikipedia.org/wiki/Tivoization https://en.m.wikipedia.org/wiki/Tivoization
  - yjftsjthsd-h 4y ago
    > Bash is not a "non-standard scripting language people like", it is the de-facto standard on Linux (heck, it was the first program Torvalds ever run on Linux) That sounds like the definition of not being standardized. BASH is the most common shell implementation on GNU systems (no, not Linux; Alpine is a Linux, and so is Android), but that doesn't make it a standard, only common. It's like claiming that nobody should care about anything but Chrome because it's "the de-facto standard". > and the most widespread implementation of POSIX shell in the world. BASH can run POSIX sh scripts, but POSIX sh can't run BASH scripts. If you're only using POSIX features, then it's not a problem, but if you're only using POSIX features we wouldn't be having this argument. > If Apple chosed tivoization[1] over freedom, so I can choose the #!/bin/bash shebang. Could I at least talk you into using `#!/usr/bin/env bash` so your scripts will work on a wider slice of the Linux universe? Even on Linux distros that exact path isn't a given (guix and nix send their regards), and you're completely breaking compatibility with the BSDs and illumos distros.
deleted 4y ago
[deleted]
tannhaeuser 4y ago
Wat? I suggest to leave such emotions out of your choice of programming languages and other decisions that should be dictated by rationality. Not adhering to POSIX shell syntax buys you very, very little, but can only create problems down the road. Bash isn't even the standard non-interactive shell on mainstream Linuxen (eg Debian uses dash), and zsh is not only used on Mac OS. [1]: https://wiki.debian.org/Shell https://wiki.debian.org/Shell

by harry8 4y ago

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.

dolni 4y ago
Nearly all of the shell scripts ever written don't need to run on Linux, and BSD, and Mac, and/or whatever esoteric Unixes that are still out there. If you are writing a shell script with the intention of running in many places, fine. But if you do that, the POSIX compatibility will be the least of your worries.

chungy 4y ago

> Why not make all your shell scripts #!/bin/bash Because it's not always installed there. See, for example, FreeBSD where bash typically lives in /usr/local/bin/bash. Or in the Linux world, Nix and Guix. Use "#!/usr/bin/env bash" to account for all these possibilities.

Ferret7446 4y ago
If we're going to be pedantic, env doesn't have to be installed at /usr/bin/env either. See https://www.felesatra.moe/blog/2021/07/03/portable-bash-shebang https://www.felesatra.moe/blog/2021/07/03/portable-bash-sheb...
tpoacher 4y ago
i cant remember where I saw it now, or what the main argument was, but I remember reading a rather authoritative article recommending against the env approach, and recommending people stick to #!/bin/bash regardless of the above, otherwise valid point. Dunno if anyone here with a better memory remembers the article to link here ...
- asicsp 4y ago
  Perhaps these? * https://unix.stackexchange.com/a/29620 https://unix.stackexchange.com/a/29620 * https://stackoverflow.com/q/21612980 https://stackoverflow.com/q/21612980

coldpie 4y ago

Serious answer, because I have users/customers who I care about that use that platform, and sometimes I use it myself. A world built on absolutes falls to pieces really quickly.

yjftsjthsd-h 4y ago

> Serious question, why should I care about portability to Apple in shell scripts? It depends on your target audience, of course, but Darwin is one of the major current OSs and wanting to support it is reasonable. > 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..? Well, for starters AFAIK /bin/bash on Darwin will give you bash 3.2, which is a bit old and feature-poor. Of course you can (and perhaps even should) simply install a new version but then it won't be at /bin/bash, it'll be under /usr/local or /opt or whatever. And BASH isn't POSIX so I'd personally argue that trying to force it makes your stuff the "second class citizen in unix". Honestly I'm not sure what position you're trying to argue. "Ignore the second biggest desktop OS because they don't ship the latest version of the non-standard scripting language I like"?

gogoyubari 4y ago
>"Ignore the second biggest desktop OS because they don't ship the latest version of the non-standard scripting language I like"? There's nothing wrong with that position. Bash is not a "non-standard scripting language people like", it is the de-facto standard on Linux (heck, it was the first program Torvalds ever run on Linux) and the most widespread implementation of POSIX shell in the world. If Apple chosed tivoization[1] over freedom, so I can choose the #!/bin/bash shebang. [1] https://en.m.wikipedia.org/wiki/Tivoization https://en.m.wikipedia.org/wiki/Tivoization
- yjftsjthsd-h 4y ago
  > Bash is not a "non-standard scripting language people like", it is the de-facto standard on Linux (heck, it was the first program Torvalds ever run on Linux) That sounds like the definition of not being standardized. BASH is the most common shell implementation on GNU systems (no, not Linux; Alpine is a Linux, and so is Android), but that doesn't make it a standard, only common. It's like claiming that nobody should care about anything but Chrome because it's "the de-facto standard". > and the most widespread implementation of POSIX shell in the world. BASH can run POSIX sh scripts, but POSIX sh can't run BASH scripts. If you're only using POSIX features, then it's not a problem, but if you're only using POSIX features we wouldn't be having this argument. > If Apple chosed tivoization[1] over freedom, so I can choose the #!/bin/bash shebang. Could I at least talk you into using `#!/usr/bin/env bash` so your scripts will work on a wider slice of the Linux universe? Even on Linux distros that exact path isn't a given (guix and nix send their regards), and you're completely breaking compatibility with the BSDs and illumos distros.

deleted 4y ago

[deleted]

tannhaeuser 4y ago

Wat? I suggest to leave such emotions out of your choice of programming languages and other decisions that should be dictated by rationality. Not adhering to POSIX shell syntax buys you very, very little, but can only create problems down the road. Bash isn't even the standard non-interactive shell on mainstream Linuxen (eg Debian uses dash), and zsh is not only used on Mac OS. [1]: https://wiki.debian.org/Shell https://wiki.debian.org/Shell