4 ms·

Its simplicity is an important part of the offering. Bash is perfect when you need predictable executions. When you use Bash, you benefit from an entire ecosys

Its simplicity is an important part of the offering. Bash is perfect when you need predictable executions. When you use Bash, you benefit from an entire ecosystem that also uses it. That same ecosystem is not motivated to drastically change the shell, and therefore it remains stable and predictable. Bash typically isn't like Python or JavaScript, where certain features are introduced at a particular version and you have to constantly check for them, or not use them outright, or maintain which binary you have installed at all times. One Bash binary typically contains the same feature set as another binary. Bash isn't the friendliest thing to work with syntactically, but it's friendlier than the alternatives in maintability and reliability. Despite all this, on the flip side, there still are a lot of people invested in alternatives, and some have gained plenty of traction. zsh is a great example.

laumars 7y ago
I don't disagree with your points but I think your following comment is a little misleading: > Bash typically isn't like Python or JavaScript, where certain features are introduced at a particular version and you have to constantly check for them, or not use them outright, or maintain which binary you have installed at all times. One Bash binary typically contains the same feature set as another binary. While you're right about shell builtins (a lot of which are defined by POSIX anyway), to do anything useful in POSIX shells requires forking out to sed, awk, grep, as well as many other coreutils and CLI tools. Thus you then need to not only confirm whether those tools are also installed but sometimes also which version or even implementation they are (eg GNU extends on POSIX in quite a number of ways from supported features through to how you order and group flags. Sometimes it can be a little jarring jumping from Linux to OSX if you're used to GNU). That said, I do working in shells. For "getting shit done" very little even comes close to shells in terms of productivity. However shells are generally optimised to the "write many read once" end of development rather than "write once read many". As an aside, I suspect GP meant to post this comment on https://news.ycombinator.com/item?id=21013150 https://news.ycombinator.com/item?id=21013150 (Pure Bash Bible - also on the front page) rather than here?
- master-litty 7y ago
  That's an oversight on my part, excellent point. Thanks for pointing it out.
- pfranz 7y ago
  > As an aside You mention it as an aside, but I think it speaks to your point about external utilities. In that thread (I also think GP intended to comment on that topic), there was confusion to what "Pure" meant. The first sentence is, "The goal of this book is to document commonly-known and lesser-known methods of doing various tasks using only built-in bash features."

laumars 7y ago

I don't disagree with your points but I think your following comment is a little misleading: > Bash typically isn't like Python or JavaScript, where certain features are introduced at a particular version and you have to constantly check for them, or not use them outright, or maintain which binary you have installed at all times. One Bash binary typically contains the same feature set as another binary. While you're right about shell builtins (a lot of which are defined by POSIX anyway), to do anything useful in POSIX shells requires forking out to sed, awk, grep, as well as many other coreutils and CLI tools. Thus you then need to not only confirm whether those tools are also installed but sometimes also which version or even implementation they are (eg GNU extends on POSIX in quite a number of ways from supported features through to how you order and group flags. Sometimes it can be a little jarring jumping from Linux to OSX if you're used to GNU). That said, I do working in shells. For "getting shit done" very little even comes close to shells in terms of productivity. However shells are generally optimised to the "write many read once" end of development rather than "write once read many". As an aside, I suspect GP meant to post this comment on https://news.ycombinator.com/item?id=21013150 https://news.ycombinator.com/item?id=21013150 (Pure Bash Bible - also on the front page) rather than here?

master-litty 7y ago
That's an oversight on my part, excellent point. Thanks for pointing it out.
pfranz 7y ago
> As an aside You mention it as an aside, but I think it speaks to your point about external utilities. In that thread (I also think GP intended to comment on that topic), there was confusion to what "Pure" meant. The first sentence is, "The goal of this book is to document commonly-known and lesser-known methods of doing various tasks using only built-in bash features."