6 ms·

If you're trying to stick to the POSIX standard, you have to use short options for standard commands like grep, since the long options are GNU extensions.

nick238 6y ago
I've given up trying to be as pure and standard as possible. I could write all my scripts to use `sh`, but `bash` can make things far easier, and in my docker containers is often required by some other package anyway, so may as well just own it.
- stjohnswarts 6y ago
  I agree, bash vs sh is night and day. Although these days I mostly use python. If I really really need something I can always shell out in python as well.
Analemma_ 6y ago
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 ...
- 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.
dathinab 6y ago
Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good. Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is easier. So if the systems you use support long options for POSIX commands go ahead and use them. Furthermore if the command you can are not in the standard anyway you again can use long options because they are as much standard as the short ones. Let's be honest this leaves very little use-cases where long options are a problem.
- kazinator 6y ago
  Last published in 2018 (and actively being worked on) is not outdated. https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ > Sure systems seen try to somewhat be POSIX compliance The mainstream systems you know and use adhere very rigorously to POSIX. GNU Libc, Kernel, Coreutils, ... and their counterparts in BSD Unixes, proprietary Unixes, Cygwin and whatnot all take POSIX seriously. POSIX is very helpful, and smart coders and sysadmins use it as one of their references for required behavior.
  - chubot 6y ago
    Larry Wall said It's easier to port a shell than a shell script in 1998 ... 22 years later I still think that holds. https://news.ycombinator.com/item?id=10104203 https://news.ycombinator.com/item?id=10104203 Although I would agree that there's a slight hole there: you still need to port stuff like coreutils and all the dependencies, which has been done of course. But I'd be happier if something like busybox was actually portable.
    - kazinator 6y ago
      I think it's easier to write a portable shell script today than 30 years ago. The Autoconf system is predicated on the idea that writing a portable shells script is hard, and so we hide the shell programming behind a mountain of M4 macros. It's not necessarily easier to port a shell script today than 22 years ago, which was not written with portability in mind. There are more shells with more extensions, and then beyond the language concerns, and the environments have exploded. A shell script can easily depend on all sorts of cruft you've never heard of. Oh, just install these five things from the following github repos ...
efrecon 6y ago
I usually test my POSIX scripts in an Alpine docker container. It has busybox by default, which only have a few flags and mostly short ones.

nick238 6y ago

I've given up trying to be as pure and standard as possible. I could write all my scripts to use `sh`, but `bash` can make things far easier, and in my docker containers is often required by some other package anyway, so may as well just own it.

stjohnswarts 6y ago
I agree, bash vs sh is night and day. Although these days I mostly use python. If I really really need something I can always shell out in python as well.

Analemma_ 6y ago

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 ...
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.

dathinab 6y ago

Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good. Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is easier. So if the systems you use support long options for POSIX commands go ahead and use them. Furthermore if the command you can are not in the standard anyway you again can use long options because they are as much standard as the short ones. Let's be honest this leaves very little use-cases where long options are a problem.

kazinator 6y ago
Last published in 2018 (and actively being worked on) is not outdated. https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ > Sure systems seen try to somewhat be POSIX compliance The mainstream systems you know and use adhere very rigorously to POSIX. GNU Libc, Kernel, Coreutils, ... and their counterparts in BSD Unixes, proprietary Unixes, Cygwin and whatnot all take POSIX seriously. POSIX is very helpful, and smart coders and sysadmins use it as one of their references for required behavior.
- chubot 6y ago
  Larry Wall said It's easier to port a shell than a shell script in 1998 ... 22 years later I still think that holds. https://news.ycombinator.com/item?id=10104203 https://news.ycombinator.com/item?id=10104203 Although I would agree that there's a slight hole there: you still need to port stuff like coreutils and all the dependencies, which has been done of course. But I'd be happier if something like busybox was actually portable.
  - kazinator 6y ago
    I think it's easier to write a portable shell script today than 30 years ago. The Autoconf system is predicated on the idea that writing a portable shells script is hard, and so we hide the shell programming behind a mountain of M4 macros. It's not necessarily easier to port a shell script today than 22 years ago, which was not written with portability in mind. There are more shells with more extensions, and then beyond the language concerns, and the environments have exploded. A shell script can easily depend on all sorts of cruft you've never heard of. Oh, just install these five things from the following github repos ...

efrecon 6y ago

I usually test my POSIX scripts in an Alpine docker container. It has busybox by default, which only have a few flags and mostly short ones.