4 ms·

I prefer long options too. However, while writing programs that need to invoke POSIX commands in a portable manner, short options are the only viable choice, a

by susam 2y ago

I prefer long options too. However, while writing programs that need to invoke POSIX commands in a portable manner, short options are the only viable choice, as POSIX doesn't specify long options. For instance, see the specification for diff at <https://pubs.opengroup.org/onlinepubs/9799919799/utilities/diff.html https://pubs.opengroup.org/onlinepubs/9799919799/utilities/d...>, or that of any POSIX utility listed at <https://pubs.opengroup.org/onlinepubs/9799919799/idx/utilities.html https://pubs.opengroup.org/onlinepubs/9799919799/idx/utiliti...>. That said, this is more of a corner case. In most scenarios, rather than relying on POSIX utilities, there are often better alternatives, such as using library bindings instead of spawning external processes. For example, instead of invoking grep, using something like libpcre could be a more efficient choice. For non-POSIX utilities like git, hg, rg, ag, etc., using long options makes perfect sense.

Wowfunhappy 2y ago
> However, while writing programs that need to invoke POSIX commands in a portable manner ...probably a stupid question, but something I have earnestly been wondering about... when does this actually happen nowadays? What POSIX systems are you targeting that aren't one of the major ones (Linux, Darwin, or one of the major BSDs)? I was writing a shell script a few months ago that I wanted to be very durable, and I targeted sh instead of bash just because, well, it seemed like the correct hacker spirit thing to do... but I don't actually know what system in the past decade (or more) wouldn't have bash.
- Gud 2y ago
  FreeBSD doesn’t come with bash though.
  - justaj 2y ago
    Nor does OpenBSD for that matter.
  - vermaden 2y ago
    But it also have drawbacks :) But being honest - you can install BASH that way: # pkg install -y bash
- cmgbhm 2y ago
  Where I can sometimes get burnt is busybox. I more often get burnt in zsh to bash than that however
- susam 2y ago
  > I don't actually know what system in the past decade (or more) wouldn't have bash. I have written a bit more about it in these comments: https://news.ycombinator.com/item?id=40681382 https://news.ycombinator.com/item?id=40681382 https://news.ycombinator.com/item?id=17074163 https://news.ycombinator.com/item?id=17074163
- chrisweekly 2y ago
  I ~recently had to wrestle w/ TeamCity (CICD) whose build agents provide only sh. I needed to invoke a 3rd-party util that required bash. The resulting "bash in dash in docker in docker" worked, but I wasn't thrilled about the convoluted / Frankenstein setup.
- mceachen 2y ago
  Alpine docker images only come with dash instead of bash, which _may_ run your sh script, but test thoroughly. Or just install bash. FWIW, Darwin/macOS is especially guilty of gobsmackingly ancient coreutils that don’t support long option variants.
  - samatman 2y ago
    Is it? I'm with you on gobsmackingly ancient, but it's "doesn't support long options" which I haven't bumped into. I do replace some coreutils, but not all of them. What's a good example of such a utility?
    - skissane 2y ago
      For example, sed. macOS sed doesn't support long options. Not even --help or --version (Running an older version of macOS so can't completely exclude this has been updated in a newer version, but I'd be surprised to learn that was true.)
  - dfe 2y ago
    macOS doesn't have GNU coreutils at all. It has the utils from FreeBSD. The gobsmackingly ancient GNU software it does have is bash, because it's the last version under GPL 2. I've used Mac OS X since 10.1, so I remember when the default shell was tcsh and /bin/sh was not bash. That's (basically) the case again on the last few macOS releases. Today, zsh is my shell of choice, including on Linux.
  - hulitu 2y ago
    P in POSIX stands for portability. ,/s
  - pingiun 2y ago
    the alpine default shell is called "ash", "dash" is the debian/ubuntu default shell
- Someone 2y ago
  > but I don't actually know what system in the past decade (or more) wouldn't have bash. I think MacOS still has bash, so that it, technically, doesn’t count, but it doesn’t have a bash from the past decade, and uses zsh by default.
- vsl 2y ago
  Major ones are enough. Linux and Darwin (that is, macOS and GNU userspace, really) differ sufficiently that you need to pay attention or limit yourself to POSIX. E.g. sed and wc burned me a few times with scripts that need to run on both.
- em500 2y ago
  > ... but I don't actually know what system in the past decade (or more) wouldn't have bash. There's some ambiguity about "have bash". If "having" bash means that (some version of) bash has been ported to the system, there are indeed very few. If "having" means that bash (supporting all options that you need) is available to the user, that could be a lot more. As others have noted, the BSDs, Android and many embedded Linux systems don't come with bash pre-installed, MacOS pre-installed bash is stuck at version 3.2 (which doesn't have associative arrays), and the user could be in an environment that does not allow them to install whatever they need.
theamk 2y ago
Note that grep in particular is extremely optimized.. If you have multi-gigabyte files, and you only search for one thing, shelling out to grep will likely have much better performance that doing it yourself. But not every system needs that much, and in a lot of cases, using your language's regexp library will be more robust anf easier to write.

by susam 2y ago

Wowfunhappy 2y ago

> However, while writing programs that need to invoke POSIX commands in a portable manner ...probably a stupid question, but something I have earnestly been wondering about... when does this actually happen nowadays? What POSIX systems are you targeting that aren't one of the major ones (Linux, Darwin, or one of the major BSDs)? I was writing a shell script a few months ago that I wanted to be very durable, and I targeted sh instead of bash just because, well, it seemed like the correct hacker spirit thing to do... but I don't actually know what system in the past decade (or more) wouldn't have bash.

Gud 2y ago
FreeBSD doesn’t come with bash though.
- justaj 2y ago
  Nor does OpenBSD for that matter.
- vermaden 2y ago
  But it also have drawbacks :) But being honest - you can install BASH that way: # pkg install -y bash
cmgbhm 2y ago
Where I can sometimes get burnt is busybox. I more often get burnt in zsh to bash than that however
susam 2y ago
> I don't actually know what system in the past decade (or more) wouldn't have bash. I have written a bit more about it in these comments: https://news.ycombinator.com/item?id=40681382 https://news.ycombinator.com/item?id=40681382 https://news.ycombinator.com/item?id=17074163 https://news.ycombinator.com/item?id=17074163
chrisweekly 2y ago
I ~recently had to wrestle w/ TeamCity (CICD) whose build agents provide only sh. I needed to invoke a 3rd-party util that required bash. The resulting "bash in dash in docker in docker" worked, but I wasn't thrilled about the convoluted / Frankenstein setup.
mceachen 2y ago
Alpine docker images only come with dash instead of bash, which _may_ run your sh script, but test thoroughly. Or just install bash. FWIW, Darwin/macOS is especially guilty of gobsmackingly ancient coreutils that don’t support long option variants.
- samatman 2y ago
  Is it? I'm with you on gobsmackingly ancient, but it's "doesn't support long options" which I haven't bumped into. I do replace some coreutils, but not all of them. What's a good example of such a utility?
  - skissane 2y ago
    For example, sed. macOS sed doesn't support long options. Not even --help or --version (Running an older version of macOS so can't completely exclude this has been updated in a newer version, but I'd be surprised to learn that was true.)
- dfe 2y ago
  macOS doesn't have GNU coreutils at all. It has the utils from FreeBSD. The gobsmackingly ancient GNU software it does have is bash, because it's the last version under GPL 2. I've used Mac OS X since 10.1, so I remember when the default shell was tcsh and /bin/sh was not bash. That's (basically) the case again on the last few macOS releases. Today, zsh is my shell of choice, including on Linux.
- hulitu 2y ago
  P in POSIX stands for portability. ,/s
- pingiun 2y ago
  the alpine default shell is called "ash", "dash" is the debian/ubuntu default shell
Someone 2y ago
> but I don't actually know what system in the past decade (or more) wouldn't have bash. I think MacOS still has bash, so that it, technically, doesn’t count, but it doesn’t have a bash from the past decade, and uses zsh by default.
vsl 2y ago
Major ones are enough. Linux and Darwin (that is, macOS and GNU userspace, really) differ sufficiently that you need to pay attention or limit yourself to POSIX. E.g. sed and wc burned me a few times with scripts that need to run on both.
em500 2y ago
> ... but I don't actually know what system in the past decade (or more) wouldn't have bash. There's some ambiguity about "have bash". If "having" bash means that (some version of) bash has been ported to the system, there are indeed very few. If "having" means that bash (supporting all options that you need) is available to the user, that could be a lot more. As others have noted, the BSDs, Android and many embedded Linux systems don't come with bash pre-installed, MacOS pre-installed bash is stuck at version 3.2 (which doesn't have associative arrays), and the user could be in an environment that does not allow them to install whatever they need.

theamk 2y ago

Note that grep in particular is extremely optimized.. If you have multi-gigabyte files, and you only search for one thing, shelling out to grep will likely have much better performance that doing it yourself. But not every system needs that much, and in a lot of cases, using your language's regexp library will be more robust anf easier to write.