Live data from Hacker News

Pure Bash Bible (2018)

github.com

21–30 of 106 posts

Re: Pure Bash Bible (2018)

#21
post #16
post #14

Depending on your job description it is completely fine to not write shell scripts. For anything bigger than a screenful of lines or something that would need proper unit testing or something that other people who are likely to be less versed in shell scripting need to maintain, think twice about using shell scripts. Unixoid machines can use anything as scripts and using a language that breathes the programming langu…

> or something that would proper unit testing https://github.com/kward/shunit2 >

And several others: https://github.com/dodie/testing-in-bash

Re: Pure Bash Bible (2018)

#22

Less critical then yesterday because of ChatGPT, I always expected to become fluent in bash at some point, but the AI became too good at writing my scripts now... Also you can use the chat as a learning tool, it's really a game changer for whom want to really learn it.

“Less critical then”

Than. Not “then,” than.

I point this out because I’m pretty sure lazy reliance on spellcheck and autocorrect are to blame with about half the internet using then when they should be using than.

I shudder to think what a few years of ChatGPT is going to do.

Re: Pure Bash Bible (2018)

#23

Earlier quoted context omitted.

That's not dash, it's bash in POSIX compatibility mode. dash does not implement all the POSIX stuff in this "bible". Imagine using this "bible" to write a "pure sh" script thinking "this will be highly portable", only to have it fail because the Linux scripting shell is not bash in POSIX compatibility mode, it's dash. It would fail on NetBSD, too, whose scripting shell is the version of ash from which dash is derived…

Do you have any specific examples to cite? The snippets are meant to be run in POSIX-compliant shells like dash/yash/ash/etc, not just Bash in compatibility mode. In fact, there used to be a section which listed workarounds[1] for bugs in dash, but they have since been fixed[2]. If you are still using an old version of dash, you may need to use them. [1] https://github.com/dylanaraps/pure-sh-bible/commit/70f410ebb...…

https://news.ycombinator.com/item?id=35768615

Perhaps dash now has these features but does NetBSD sh or FreeBSD sh have them.

What's the point of "pure sh" if it's restricted to specific versions of shells. Opinions may differ but I'd rather learn the "lowest common denominator". I use the same scripts on both Linux and BSD so I need portability. I do not use bash for scripting. It's larger and slower.

One source I consult is https://www.in-ulm.de/~mascheck/bourne/

It is sometimes submitted to HN, but not IMO enough

https://news.ycombinator.com/from?site=in-ulm.de

I'm using the latest version of dash. I just tested it and it does have these ternary operators. However, I'm not going to use them in scripts unless I know they'll work on older dash versions, OpenWRT sh, Android sh, NetBSD sh, FreeBSD sh, etc. The process of updating these shells is generally very slow. It can take years.

"Pure sh" implies there is some advantage over "bashisms". I thought maybe it was portability but perhaps it is something else.

Re: Pure Bash Bible (2018)

#24
post #14

Depending on your job description it is completely fine to not write shell scripts. For anything bigger than a screenful of lines or something that would need proper unit testing or something that other people who are likely to be less versed in shell scripting need to maintain, think twice about using shell scripts. Unixoid machines can use anything as scripts and using a language that breathes the programming langu…

I typically agree, but I don't think its as simple as a "screenful of lines" criteria.

I find it useful when most of your work is wiring other command line tools together. When that's most of your work, shell scripting feels like it has the best affordances.

Anything that gets too fancy beyond this, with anything that resembles an algorithm or computation, you'll feel real pain :) Bash doesn't even support floating point!

Re: Pure Bash Bible (2018)

#25
post #22

Less critical then yesterday because of ChatGPT, I always expected to become fluent in bash at some point, but the AI became too good at writing my scripts now... Also you can use the chat as a learning tool, it's really a game changer for whom want to really learn it.

“Less critical then” Than. Not “then,” than. I point this out because I’m pretty sure lazy reliance on spellcheck and autocorrect are to blame with about half the internet using then when they should be using than. I shudder to think what a few years of ChatGPT is going to do.

I agree!

Re: Pure Bash Bible (2018)

#26

Less critical then yesterday because of ChatGPT, I always expected to become fluent in bash at some point, but the AI became too good at writing my scripts now... Also you can use the chat as a learning tool, it's really a game changer for whom want to really learn it.

> I always expected to become fluent in bash at some point, but the AI became too good at writing my scripts now...

This page :

https://mywiki.wooledge.org/BashPitfalls

Is the fastest way of becoming proficient with shell scripting. Whether it's pure posix shell, or bash and its extensions, they're small languages and can be learned in a week end if you're proficient in another programming language. The main pain point is that there's a lot of "surprises" and non-intuitive behaviors, that are all listed here. The first ones, about parameter expansions, quoting variables and leading dashes are the most common issue with newbies in shell scripting.

There's a lot of amazing tooling these days to make sure your shell scripts are fine too. First, shellcheck:

https://www.shellcheck.net/

I systematically run this on my scripts before using them.

Then shfmt for nice, reliable autoformatting: https://github.com/mvdan/sh

And finally, checkbashisms if you intend on making pure posix scripts that are compatible with debian/ubuntu's dash. It is part of the debian's devscripts suite, but is often individually packaged in other distros.

> Also you can use the chat as a learning tool

Or you could learn from a guide written by people who have suffered decades of experience of the pitfalls of shell scripting and have shared their woes.

https://mywiki.wooledge.org/BashGuide

chatGPT is good at coming up with magical solutions, but teaching you about all the corner cases?

Re: Pure Bash Bible (2018)

#27

I'd love to see a little language which compiles to _readable_ bash. Could it be so hard? There's a dead project that comes up now and then called bish. https://github.com/tdenniston/bish

One of my current hobby projects is a scripting language which compiles to POSIX sh (for maximum portability). However, it's far from complete, the output is not exactly readable and POSIX sh is so limited that I might need to change course and target something else.

EDIT: I didn't know of Bish, but from its code samples we seem to have converged on similar syntax :)

Re: Pure Bash Bible (2018)

#28

Earlier quoted context omitted.

Do you have any specific examples to cite? The snippets are meant to be run in POSIX-compliant shells like dash/yash/ash/etc, not just Bash in compatibility mode. In fact, there used to be a section which listed workarounds[1] for bugs in dash, but they have since been fixed[2]. If you are still using an old version of dash, you may need to use them. [1] https://github.com/dylanaraps/pure-sh-bible/commit/70f410ebb...…

https://news.ycombinator.com/item?id=35768615 Perhaps dash now has these features but does NetBSD sh or FreeBSD sh have them. What's the point of "pure sh" if it's restricted to specific versions of shells. Opinions may differ but I'd rather learn the "lowest common denominator". I use the same scripts on both Linux and BSD so I need portability. I do not use bash for scripting. It's larger and slower. One source I c…

> and slower.

I like to write posix sh scripts for the sake of portability and, funnily enough, future proofing as I don't like having to maintain stuff against changes that break compatibility, which is something bash does (archlinux is still on an older bash even though debian stable has the latest, because bash 5.2 broke some of archlinux's own scripts. This is why you should not write bash scripts.), but bash being slow isn't one of the good reasons. If your scripts do that much work that your shell's speed matters, you should reconsider writing shell scripts and start thinking about using something like perl, python or ruby. I'd suggest perl, if only because unlike the latter, perl doesn't constantly pull the rug under you and make you do busy work to make sure your scripts work on the latest runtimes.

Post reply on HN