trim_string() {
# Usage: trim_string " example string "
: "${1#"${1%%[![:space:]]*}"}"
: "${_%"${_##*[![:space:]]}"}"
printf '%s\n' "$_"
}And my bash code would probably be more readable if I started collecting common operations in a function library rather than repeating the same sed/awk incantations that aren't super readable. At that point might as well use pure bash/sh implementations to save spawning a new process when reasonable.
if [ -z "$foo" ]
then :
else echo not blank "$foo"
fiI often use it instead of truncate or touch
: > somefile
: >> somefile
: is not lexically special (the way # is), you can use : in variable and function names, even create a function called just ":" if you're trying to confuse...
“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.
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.
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.
$ ./testtrim
./testtrim
$ sed -i 's/dash/bash/' testtrim
$ ./testtrim
foo bar
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.
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.
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.
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
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.
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.
> 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
Sometimes, it's genuinely better to plug on in shell (e.g. if you are just calling other scripts and chaining stuff), but, especially if you want some less-magical string or list manipulations, often Python/Perl will provide a more readable, more maintainable, more _testable_ script. YMMV with Perl.
I mean it's parameter expansion, just flip down to that section of the manpage, and then there is posix regex in there. Not too difficult to look up in the manpages.