3 ms·

Ideally, the function is POSIX-compatible, so it runs on the widest number of platforms. Why do we want to adhere to POSIX? $ man bash | grep slow

by chasil 5y ago

Ideally, the function is POSIX-compatible, so it runs on the widest number of platforms. Why do we want to adhere to POSIX? $ man bash | grep slow It's too big and too slow. $ rpm -qi dash | tail -3 DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. It does this without sacrificing speed where possible. In fact, it is significantly faster than bash (the GNU Bourne-Again SHell) for most tasks. So let's find out how this function works in dash. $ ./testtrim ./testtrim $ sed -i 's/dash/bash/' testtrim $ ./testtrim foo bar I think I will pass.

bewuethr 5y ago
There is https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible, including a trim function.
- chasil 5y ago
  That is a better resource. The two important places for portability are Ubuntu's /bin/sh (which is dash, not bash), and the Busybox shell. Commercial unix would be important, but is likely a distant 3rd by the numbers.
mkdirp 5y ago
> Ideally, the function is POSIX-compatible, so it runs on the widest number of platforms. But... Why? During my professional career of about 10 years, and even before that, I've not once had to require POSIX compatibility for any of the shell scripts I've written or come across. The few times I had a snippet that couldn't run I have been able to install bash 4+ with ease. I'm sure there are times where POSIX is kind of needed, but it's becoming exceedingly rare.
- chasil 5y ago
  I have a Korn shell script that I use to run SQL against a few dozen databases. I recently rewrote this script, so it would run on Windows, via Busybox ash. It needed quite a few changes. I've become somewhat practiced on the removal of bashisms. Oddly enough I had to put a few back. Busybox on Windows doesn't implement stty that I needed to read a password, but it did have read -s, so I used that instead. I threw several snippets of ash-emulated bash back in, that would never ever run on dash. When you ask "but why?" this is precisely why - I need this functionality in a specific place, where you cannot go.
- _lqaf 5y ago
  The Linux monoculture in internet services does reduce the value of POSIX-compliance. I got in the habit of at least gesturing towards POSIX back when it was more common to run a bunch of different unixes. And I still run both FreeBSD and Linux at home, so there's value there for me. Mostly, I still do it because I'm always surprised by which artifacts I create end up being long-lived, and you never know what will be valuable in the future. One of the things I'm technically proudest of ended up only being useful for less than a year, whereas I know a dumb 4 line hack I wrote on a contract in 2002 is still running via cron every night, now on a VM in AWS.
  - chasil 5y ago
    I think it would be helpful if we can update the POSIX shell standard. This is the only way that the Debian/Ubuntu /bin/sh will ever change. Microsoft was pivotal in the formation of the standard, as Korn was required to run in a 64k text segment for Xenix, and this was retained for POSIX.2. The parser for the Borne family is very complex, and cannot be implemented with a yacc grammar. There is some value in starting again with something less convoluted. This guy tried to implement a POSIX shell in OCaml, and he is rather perturbed with the entire Borne family (I wish I knew parsers this well): https://m.youtube.com/watch?v=fiJR4_059HA https://m.youtube.com/watch?v=fiJR4_059HA Bash has a number of real strikes against it... GPLv3 - which caused Apple to dump it, speed - which caused Debian/Ubuntu to demote it, and the lingering damage bashisms and their damage to portability.
    - chasil 5y ago
      This discussion of a high-performance POSIX shell for Windows is also enlightening. https://video.fosdem.org/2019/AW1.125/ada_shell.webm https://video.fosdem.org/2019/AW1.125/ada_shell.webm
- pavon 5y ago
  I can't think of any time where I have needed the same script to run on multiple systems, because that's not the sort of thing I use shell scripts for. But there are many times where I have needed to write a script for a specific system that was running busybox or dash or ksh, and it is worth knowing what features I can use in those cases.
  - kergonath 5y ago
    But then your source is probably not something called “Pure Bash Bible”.
kergonath 5y ago
That’s why you put things like #!/usr/bin/env bash. You can argue about which version of bash supporting which feature, but being afraid to have your own scripts interpreted by POSIX sh is strange in the vast majority of situations. It’s like complaining that a C++ source would not be compiled by a strict C compiler. Or that Python 3 scripts should be valid Python 2 because you never know which version ‘python’ might be. Just use the right interpreter.

by chasil 5y ago

bewuethr 5y ago

There is https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible, including a trim function.

chasil 5y ago
That is a better resource. The two important places for portability are Ubuntu's /bin/sh (which is dash, not bash), and the Busybox shell. Commercial unix would be important, but is likely a distant 3rd by the numbers.

mkdirp 5y ago

> Ideally, the function is POSIX-compatible, so it runs on the widest number of platforms. But... Why? During my professional career of about 10 years, and even before that, I've not once had to require POSIX compatibility for any of the shell scripts I've written or come across. The few times I had a snippet that couldn't run I have been able to install bash 4+ with ease. I'm sure there are times where POSIX is kind of needed, but it's becoming exceedingly rare.

chasil 5y ago
I have a Korn shell script that I use to run SQL against a few dozen databases. I recently rewrote this script, so it would run on Windows, via Busybox ash. It needed quite a few changes. I've become somewhat practiced on the removal of bashisms. Oddly enough I had to put a few back. Busybox on Windows doesn't implement stty that I needed to read a password, but it did have read -s, so I used that instead. I threw several snippets of ash-emulated bash back in, that would never ever run on dash. When you ask "but why?" this is precisely why - I need this functionality in a specific place, where you cannot go.
_lqaf 5y ago
The Linux monoculture in internet services does reduce the value of POSIX-compliance. I got in the habit of at least gesturing towards POSIX back when it was more common to run a bunch of different unixes. And I still run both FreeBSD and Linux at home, so there's value there for me. Mostly, I still do it because I'm always surprised by which artifacts I create end up being long-lived, and you never know what will be valuable in the future. One of the things I'm technically proudest of ended up only being useful for less than a year, whereas I know a dumb 4 line hack I wrote on a contract in 2002 is still running via cron every night, now on a VM in AWS.
- chasil 5y ago
  I think it would be helpful if we can update the POSIX shell standard. This is the only way that the Debian/Ubuntu /bin/sh will ever change. Microsoft was pivotal in the formation of the standard, as Korn was required to run in a 64k text segment for Xenix, and this was retained for POSIX.2. The parser for the Borne family is very complex, and cannot be implemented with a yacc grammar. There is some value in starting again with something less convoluted. This guy tried to implement a POSIX shell in OCaml, and he is rather perturbed with the entire Borne family (I wish I knew parsers this well): https://m.youtube.com/watch?v=fiJR4_059HA https://m.youtube.com/watch?v=fiJR4_059HA Bash has a number of real strikes against it... GPLv3 - which caused Apple to dump it, speed - which caused Debian/Ubuntu to demote it, and the lingering damage bashisms and their damage to portability.
  - chasil 5y ago
    This discussion of a high-performance POSIX shell for Windows is also enlightening. https://video.fosdem.org/2019/AW1.125/ada_shell.webm https://video.fosdem.org/2019/AW1.125/ada_shell.webm
pavon 5y ago
I can't think of any time where I have needed the same script to run on multiple systems, because that's not the sort of thing I use shell scripts for. But there are many times where I have needed to write a script for a specific system that was running busybox or dash or ksh, and it is worth knowing what features I can use in those cases.
- kergonath 5y ago
  But then your source is probably not something called “Pure Bash Bible”.

kergonath 5y ago

That’s why you put things like #!/usr/bin/env bash. You can argue about which version of bash supporting which feature, but being afraid to have your own scripts interpreted by POSIX sh is strange in the vast majority of situations. It’s like complaining that a C++ source would not be compiled by a strict C compiler. Or that Python 3 scripts should be valid Python 2 because you never know which version ‘python’ might be. Just use the right interpreter.