4 ms·

Unless you count things like Makefiles, I don't think I've ever written or encountered a "script" that was intended for use on multiple *nix flavors. This strik

Unless you count things like Makefiles, I don't think I've ever written or encountered a "script" that was intended for use on multiple *nix flavors. This strikes me as a YAGNI situation: do it if it comes up, but not before.

lhoursquentin 6y ago
Yes most of the time the respecting POSIX to the letter is not needed, but it is of course satisfying knowing that your script can run fine on BSDs and other less common distributions :) Though sometimes you don't need to go that far to break stuff, for instance switching from Fedora to Ubuntu. I've seen many scripts fail on debian derivatives because people think using #!/bin/sh as a shebang is fine since it works on their computer where sh was in fact a symlink to bash. But on debian based distributions /bin/sh is often dash, not bash, and dash is basically the strict POSIX subset + local, all fancy stuff like [[ ]], &>, arrays, ... will fail. Though this is less about long options here and more about general shell scripting.
- kazinator 6y ago
  You don't know that your script will run fine anywhere, if you've not actually run it there. But, still, that's no reason to adopt a mindset of actively wrecking the chances of such success. (Which is what passive ignorance amounts to, effectively).
ori_b 6y ago
This attitude is definitely something that makes my life harder. My OS is usually OpenBSD, and I constantly need to fix other people's scripts. It's not difficult to do, but it is annoying. I don't blame people for ignorance, but it'd be nice if people thought about portability. Non-portable scripts can also bite you on Linux, where Debian, for example, will swap out the shell from bash to dash for performance. but others will not. So, even within the Linux ecosystem, you can end up with scripts that behave differently across distros.
- jfrunyon 6y ago
  Sounds to me like your choice of OS is what makes your life harder...
  - ori_b 6y ago
    It makes my life easier in most ways. This is one of the costs. And, again, this still bites whenever using different linux distros.
    - jfrunyon 6y ago
      I never said that wasn't the case. That doesn't mean anyone else's attitude is the cause of problems caused by your own choices. #!/bin/bash
      - ori_b 6y ago
        I think you mean #!/usr/bin/env bash
        jfrunyon 6y ago
        Nope, I don't.
- jjgreen 6y ago
  It's really useful to have a *BSD user or two in your userbase complaining about your non-POSIX linuxisms, it improves the portability of your code no end ...
- rascul 6y ago
  > Non-portable scripts can also bite you on Linux, where Debian, for example, will swap out the shell from bash to dash for performance. but others will not. So, even within the Linux ecosystem, you can end up with scripts that behave differently across distros. From the bash man page, "If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well." Also you should not be including bashisms if your shebang is sh and not bash. So using bash as sh shouldn't generally be a problem, if you stick to the published Shell Command Language [0], unless you hit one of the cases where the spec is a bit ambiguous and shells implement it differently [1]. [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... [1] https://stackoverflow.com/questions/16069339/different-pipeline-behavior-between-sh-and-ksh/16322932#16322932 https://stackoverflow.com/questions/16069339/different-pipel...
samtheprogram 6y ago
Portable shell scripts probably run on your system all the time, e.g. when installing development tools or packages, especially for cross-platform languages like Node.js, Ruby, Python, etc... If a hunk of software wants a shell script, it's gonna be portable. Homebrew comes to mind, and any other piece of software that does the installation via a shell script.
kazinator 6y ago
If you've ever run a ./configure script before building a program, you have encountered a script intended for use on multiple Unix flavors.
kelnos 6y ago
I think that's a reasonable attitude to have for your own personal scripts that you use on your own machines. But for stuff you do for work it might make sense to go for portability. Where I work most people develop on macOS, and our infra runs on Linux. I happen to develop on Linux, but if I'm writing development scripts that are intended to be run locally, I can't assume that GNU tools will be installed everywhere.
viraptor 6y ago
There's a good chance you did. Lots of opensource developers use MacOS, so there's at least compatibility between that and Linux.

lhoursquentin 6y ago

Yes most of the time the respecting POSIX to the letter is not needed, but it is of course satisfying knowing that your script can run fine on BSDs and other less common distributions :) Though sometimes you don't need to go that far to break stuff, for instance switching from Fedora to Ubuntu. I've seen many scripts fail on debian derivatives because people think using #!/bin/sh as a shebang is fine since it works on their computer where sh was in fact a symlink to bash. But on debian based distributions /bin/sh is often dash, not bash, and dash is basically the strict POSIX subset + local, all fancy stuff like [[ ]], &>, arrays, ... will fail. Though this is less about long options here and more about general shell scripting.

kazinator 6y ago
You don't know that your script will run fine anywhere, if you've not actually run it there. But, still, that's no reason to adopt a mindset of actively wrecking the chances of such success. (Which is what passive ignorance amounts to, effectively).

ori_b 6y ago

This attitude is definitely something that makes my life harder. My OS is usually OpenBSD, and I constantly need to fix other people's scripts. It's not difficult to do, but it is annoying. I don't blame people for ignorance, but it'd be nice if people thought about portability. Non-portable scripts can also bite you on Linux, where Debian, for example, will swap out the shell from bash to dash for performance. but others will not. So, even within the Linux ecosystem, you can end up with scripts that behave differently across distros.

jfrunyon 6y ago
Sounds to me like your choice of OS is what makes your life harder...
- ori_b 6y ago
  It makes my life easier in most ways. This is one of the costs. And, again, this still bites whenever using different linux distros.
  - jfrunyon 6y ago
    I never said that wasn't the case. That doesn't mean anyone else's attitude is the cause of problems caused by your own choices. #!/bin/bash
    - ori_b 6y ago
      I think you mean #!/usr/bin/env bash
      - jfrunyon 6y ago
        Nope, I don't.
jjgreen 6y ago
It's really useful to have a *BSD user or two in your userbase complaining about your non-POSIX linuxisms, it improves the portability of your code no end ...
rascul 6y ago
> Non-portable scripts can also bite you on Linux, where Debian, for example, will swap out the shell from bash to dash for performance. but others will not. So, even within the Linux ecosystem, you can end up with scripts that behave differently across distros. From the bash man page, "If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well." Also you should not be including bashisms if your shebang is sh and not bash. So using bash as sh shouldn't generally be a problem, if you stick to the published Shell Command Language [0], unless you hit one of the cases where the spec is a bit ambiguous and shells implement it differently [1]. [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... [1] https://stackoverflow.com/questions/16069339/different-pipeline-behavior-between-sh-and-ksh/16322932#16322932 https://stackoverflow.com/questions/16069339/different-pipel...

samtheprogram 6y ago

Portable shell scripts probably run on your system all the time, e.g. when installing development tools or packages, especially for cross-platform languages like Node.js, Ruby, Python, etc... If a hunk of software wants a shell script, it's gonna be portable. Homebrew comes to mind, and any other piece of software that does the installation via a shell script.

kazinator 6y ago

If you've ever run a ./configure script before building a program, you have encountered a script intended for use on multiple Unix flavors.

kelnos 6y ago

I think that's a reasonable attitude to have for your own personal scripts that you use on your own machines. But for stuff you do for work it might make sense to go for portability. Where I work most people develop on macOS, and our infra runs on Linux. I happen to develop on Linux, but if I'm writing development scripts that are intended to be run locally, I can't assume that GNU tools will be installed everywhere.

viraptor 6y ago

There's a good chance you did. Lots of opensource developers use MacOS, so there's at least compatibility between that and Linux.