4 ms·

> I agree that even Python with stdlib-only is still better than Bash, but I guarantee that you'll find Bash >=3.0 on every host. Shouldn't you go for POSIX at

by hiq 6y ago

> I agree that even Python with stdlib-only is still better than Bash, but I guarantee that you'll find Bash >=3.0 on every host. Shouldn't you go for POSIX at that point? I'm not an expert, but I still have some idea how to test that my script is (somewhat) POSIX compliant (e.g. use shellcheck, run the script with dash or a shell in POSIX-compatible mode). I have Bash 5 on my Debian, how do I test that a script I tested with this version works on Bash 3 as well? Or have the changes between Bash 3 and Bash 5 been so minimal that I would have to do it on purpose to find an incompatibility? I'm also curious about the number of machines where Bash scripts are run but don't have, say, Python 3.4 installed, and projects where it's a better trade-off to spend time developing and testing in Bash rather than have a Python 3 dependency. I'd say it's relatively rare.

chubot 6y ago
Bash also has a -o posix option, which changes a number of things which may be significant, but I rarely see it used. But none of those 3 solutions really check for POSIX compliance (including -o posix, since of course you can use many non-POSIX features when it's on). I am not aware that ShellCheck actually checks POSIX compliance; I am pretty sure it just checks for common errors in your bash/sh scripts (which is what it says on the home page). I think what you may mean is "portable shell", i.e. portable between shell X and Y and system X and Y. That is a decent goal but many people use bash just because it alone is portable enough! The system tools are often unportable though. Limiting yourself to POSIX in that case is pretty painful and also virtually untestable. It's better to say "portable between X and Y" because I think that's what you mean. In other words, there is plenty of stuff that's portable but not POSIX that you probably want to use. local variables are probably the biggest example. Every shell I know of supports those, including dash, but it's not POSIX (though maybe they're thinking about adding it; the spec is pretty behind) I addressed this somewhat here: http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#limit-to-posix http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#li...
- bewuethr 6y ago
  For scripts with a #/bin/sh shebang line, ShellCheck points out bashisms.
- hiq 6y ago
  > I am not aware that ShellCheck actually checks POSIX compliance; I am pretty sure it just checks for common errors in your bash/sh scripts Bashisms are errors if you specify #!/bin/sh. If you want to try it out, you can load random examples on https://www.shellcheck.net/ https://www.shellcheck.net/ until you get a #!/bin/sh. Then you'll get warnings such as "SC3010: In POSIX sh, [[ ]] is undefined." To go back to the discussion: if you want to use Bash features, you're better off switching to Python.
  - chubot 6y ago
    OK interesting, yeah with #!/bin/sh it points out that 'local' is not POSIX. But every shell I know of supports 'local'. It's not a "bash-ism' because it's universally supported. I consider it essential; otherwise you might as well not use functions in shell. This is a long argument (and is addressed in the same FAQ), but as someone who's written hundreds of thousands of lines of Python, I think shell is still better for a large set of tasks. A typical small project I write might have 300 lines of shell and 1000 lines of Python, rather than 5000 lines of Python. But of course there are problems with using shell; if there weren't then Oil wouldn't exist :)
    - justaj 6y ago
      AFAIK unsetting the variables first works too.
ian-g 6y ago
I had something like this in my last job: I had to create an installer for a VCS aimed at chip designer. The installer would be ignored as much as my coworkers could manage, and as many customers as possible had to be able to just use it unmodified. Since our supported OSes were RHEL6, RHEL7, SLES12, and SLES15, the best option was bash. Also had to build it on the off chance one of our more restrictive customers was still on RHEL5.11 Pain in the butt, but it worked.

by hiq 6y ago

chubot 6y ago

Bash also has a -o posix option, which changes a number of things which may be significant, but I rarely see it used. But none of those 3 solutions really check for POSIX compliance (including -o posix, since of course you can use many non-POSIX features when it's on). I am not aware that ShellCheck actually checks POSIX compliance; I am pretty sure it just checks for common errors in your bash/sh scripts (which is what it says on the home page). I think what you may mean is "portable shell", i.e. portable between shell X and Y and system X and Y. That is a decent goal but many people use bash just because it alone is portable enough! The system tools are often unportable though. Limiting yourself to POSIX in that case is pretty painful and also virtually untestable. It's better to say "portable between X and Y" because I think that's what you mean. In other words, there is plenty of stuff that's portable but not POSIX that you probably want to use. local variables are probably the biggest example. Every shell I know of supports those, including dash, but it's not POSIX (though maybe they're thinking about adding it; the spec is pretty behind) I addressed this somewhat here: http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#limit-to-posix http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#li...

bewuethr 6y ago
For scripts with a #/bin/sh shebang line, ShellCheck points out bashisms.
hiq 6y ago
> I am not aware that ShellCheck actually checks POSIX compliance; I am pretty sure it just checks for common errors in your bash/sh scripts Bashisms are errors if you specify #!/bin/sh. If you want to try it out, you can load random examples on https://www.shellcheck.net/ https://www.shellcheck.net/ until you get a #!/bin/sh. Then you'll get warnings such as "SC3010: In POSIX sh, [[ ]] is undefined." To go back to the discussion: if you want to use Bash features, you're better off switching to Python.
- chubot 6y ago
  OK interesting, yeah with #!/bin/sh it points out that 'local' is not POSIX. But every shell I know of supports 'local'. It's not a "bash-ism' because it's universally supported. I consider it essential; otherwise you might as well not use functions in shell. This is a long argument (and is addressed in the same FAQ), but as someone who's written hundreds of thousands of lines of Python, I think shell is still better for a large set of tasks. A typical small project I write might have 300 lines of shell and 1000 lines of Python, rather than 5000 lines of Python. But of course there are problems with using shell; if there weren't then Oil wouldn't exist :)
  - justaj 6y ago
    AFAIK unsetting the variables first works too.

ian-g 6y ago

I had something like this in my last job: I had to create an installer for a VCS aimed at chip designer. The installer would be ignored as much as my coworkers could manage, and as many customers as possible had to be able to just use it unmodified. Since our supported OSes were RHEL6, RHEL7, SLES12, and SLES15, the best option was bash. Also had to build it on the off chance one of our more restrictive customers was still on RHEL5.11 Pain in the butt, but it worked.