4 ms·
I understand your concerns about bash features and POSIX compatibility. The bash bible was written specifically to document the shell extensions bash implements
by dyanaraps 7y ago
I understand your concerns about bash features and POSIX compatibility. The bash bible was written specifically to document the shell extensions bash implements.
My focus for the past few months has been writing a Linux distribution (and its package manager/tooling) in POSIX sh.
I've learned a lot of tricks and I'm very tempted to write a second "bible" with snippets that are supported in all POSIX shells.
(I created the bash bible).
- acqq 7y ago> I've learned a lot of tricks and I'm very tempted to write a second "bible" with snippets that are supported in all POSIX shells. That could be potentially even more interesting than a bash-specific one (as it is harder to get it right -- bash can be figured out out of the single reference, anything "portable" has many dependencies).
- dyanaraps 7y agoOff the top of my head, a few notable things I've learned: - Safely working with "string lists" (list="el el el el"). - Filtering out duplicate items. - Reversing the list. - etc. - Using `case` to do sub-string matching (using globbing). - Using `set -- el el el` to create an "array" (only one array at a time!). - `read -r` is still powerful in POSIX `sh` for getting data out of files. `while read -r` even more so. - POSIX `sh` has `set -e` and friends so you can exit on errors etc. - Ternary operators still exist for arithmetic (`$(($# > 0 ? 1 : 0))`). - Each POSIX `sh` shell has a set of quirks you need to account for. What works in one POSIX `sh` shell may not in another. (I found a set of differences between `ash`/`dash` in my testing). POSIX `sh` is a very simple language compared to `bash` and all of its extensions so there won't be as many snippets but there's some gold to be found.
- dyanaraps 7y agoI've started working on it here: https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible
- acqq 7y agoI see you already made progress there! Congratulations!
- 0xdeadb00f 7y agoI'd be very interested in a POSIX sh version of this bash bible.
- dyanaraps 7y agoI've started working on it here: https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible
- tannhaeuser 7y agoYou can add me to those interested in a pure POSIX shell bible. Whenever I'm about to write a moderately large script, I'm actively avoiding bashisms as they don't buy me much yet make my script unportable. But, given you've spent so much time on this subject, are there any bashisms that are truly essential and you don't want to live without?
- dyanaraps 7y ago> You can add me to those interested in a pure POSIX shell bible. I've started working on it here: https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible > are there any bashisms that are truly essential and you don't want to live without? The only thing I'd say I miss when writing POSIX `sh` is arrays. I work around this by using 'set -- 1 2 3 4' to mimic an array using the argument list. The limitation here though is that you're limited to one "array" at a time. The other alternative I make use of is to use "string lists" (list="1 2 3 4") with word splitting. This can be made safe if the following is correct: - Globbing is disabled. - You control the input data and can safely make assumptions (no spaces or new lines in elements). While it's something that'd be nice to have, there are ways to work around it. EDIT: One more thing would be "${var:0:1}" to grab individual characters from strings (or ranges of characters from strings).
- akdor1154 7y agoset -o pipefail
- scbrg 7y agoThat, and local variables. I avoid bash for the same reasons as GP, so I tend to (reluctantly) live without pipefail and work around the lack of local variables with subshells (which I assume has a performance impact - but hey).
- tannhaeuser 7y agoI just wanted to add I'd be very interested in your shell-based package manager as well!