5 ms·

I mean, does it really need to be readable? I kind of took this site to be “here’s some snippets of code that you can use in your scripts to use instead of call

by mttjj 5y ago

I mean, does it really need to be readable? I kind of took this site to be “here’s some snippets of code that you can use in your scripts to use instead of calling an external process.” Which means to me, I’m going to copy/paste this function into my script, call the function (since it’s structured as one), and never think about it again. “Learn how to write routines like this and make them readable” seems like it’s not the point of this “Bible”. I’m not against readable code by any means (maybe there’s even a cleaner way to write this) but it seemed inconsequential in my opinion.

aloisdg 5y ago
I am more and more on your side. If this function was a builtin, how many reader will check its implementation?
- jteppinette 5y ago
  But it is not a builtin. Someone else is going to have to maintain this one day. > insert quote about writing your code as if the person who will have to maintain it next is a violent psychopath who knows where you live
  - adhesive_wombat 5y ago
    This maybe true even if the next person to maintain that is yourself! I have certainly wished terrible vengeance to be visited on past me.
- throwamon 5y ago
  Totally agreed. While we're at it, let's make Brainfuck the official POSIX shell language.
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.
queuebert 5y ago
> I mean, does it really need to be readable? Yes, because it says it trims strings, but is otherwise unreadable to most people. If they have a bug in their script caused by this function not working correctly, good luck finding it.

by mttjj 5y ago

aloisdg 5y ago

I am more and more on your side. If this function was a builtin, how many reader will check its implementation?

jteppinette 5y ago
But it is not a builtin. Someone else is going to have to maintain this one day. > insert quote about writing your code as if the person who will have to maintain it next is a violent psychopath who knows where you live
- adhesive_wombat 5y ago
  This maybe true even if the next person to maintain that is yourself! I have certainly wished terrible vengeance to be visited on past me.
throwamon 5y ago
Totally agreed. While we're at it, let's make Brainfuck the official POSIX shell language.

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.

queuebert 5y ago

> I mean, does it really need to be readable? Yes, because it says it trims strings, but is otherwise unreadable to most people. If they have a bug in their script caused by this function not working correctly, good luck finding it.