Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pure Bash Bible

github.com

Post reply on HN
Print view View original

91–100 of 258 posts

Re: Pure Bash Bible

#91

Post by Tepix »

Jenz wrote: post #85

Looking at the very first example: trim_string(){ # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } This reads horrible. I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external programs/commands.

> This reads horrible.

Just use the shell function by its descriptive name...

The reasons are explained in the foreword:

Calling an external process in bash is expensive and excessive use will cause a noticeable slowdown. Scripts and programs written using built-in methods (where applicable) will be faster, require fewer dependencies and afford a better understanding of the language itself.

Re: Pure Bash Bible

#92

Post by dyanaraps »

davidrm wrote: post #78
dyanaraps wrote: post #15

Hello, I'm the author of the Pure Bash Bible. Happy to answer any questions you may have. Here's an example of what bash is capable of: https://github.com/dylanaraps/fff/ (a TUI file manager written in bash)!

completely unrelated, it's so funny that i saw this comment, looked at your name and thought "hey, i know this guy!". it turns out i forked your dotfiles ages ago when i first started playing with i3. also neofetch is pretty cool!

Thanks!

Re: Pure Bash Bible

#93

Post by dyanaraps »

hnarn wrote: post #67
dyanaraps wrote: post #15

Hello, I'm the author of the Pure Bash Bible. Happy to answer any questions you may have. Here's an example of what bash is capable of: https://github.com/dylanaraps/fff/ (a TUI file manager written in bash)!

This might be an odd/off-topic question, but in Telegram this article has an auto-fetched thumbnail of a cat smoking a cigarette and a text similar to 'heavy metal music playing', I'm just curious where this picture is from, if you have any idea? I checked the README for the repo, pictures of the contributors etc. but I'm unable to figure out where it's coming from.

That's a very very very old GitHub avatar of mine, I wonder why Telegram hasn't pulled a later one.

Re: Pure Bash Bible

#94

Post by Crinus »

jigglesniggle wrote: post #4

While this is interesting I see doing anything but launching programs with simple text-substituted arguments as too much for bash or sh. Run shellcheck on some of your own code, or the code of even a simple project to see how hard it is to really use bash. Why I think people gravitate towards it is because languages such as python add too much pomp to launching a shell process. A language like perl is usually easier…

One reason i prefer Bash (and i mean Bash not just any shell) is that it tends to stay stable - scripts written years ago work just fine today. These days i mainly use Bash on Windows (via MSYS2) and really it is available pretty much everywhere, either out of the box or via installation.

If anything code that i used to write in Python at the past i write it in Bash nowadays, exactly because Bash has a better record when it comes to not breaking stuff. Though it helps that my Python use is also mostly scripts meant to run from the shell.

Re: Pure Bash Bible

#95

Post by hnlmorg »

collyw wrote: post #88
Jenz wrote: post #85

Looking at the very first example: trim_string(){ # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } This reads horrible. I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external programs/commands.

> I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external commands. Are there systems that don't come with sed installed? (Some docker containers I have logged into don't seem to have less).

I've never known `sed` not be installed but I have been caught out by different implementations of sed before.

Re: Pure Bash Bible

#96

Post by Jenz »

collyw wrote: post #88
Jenz wrote: post #85

Looking at the very first example: trim_string(){ # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } This reads horrible. I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external programs/commands.

> I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external commands. Are there systems that don't come with sed installed? (Some docker containers I have logged into don't seem to have less).

Well, less is only intended for interactive use AFAIK, in contrast to sed which is very much scriptable; and part of the POSIX standard [1]

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...

Re: Pure Bash Bible

#97

Post by dyanaraps »

jgtrosh wrote: post #87
dyanaraps wrote: post #59

Earlier quoted context omitted.

> Have you read Bash Pitfalls[1]? I've read pretty much everything I could get my hands on regarding the shell (including the mentioned link) and I still love it. > Do you write truly correct Bash/POSIX code? If we define correct as passing shellcheck, avoiding all pitfalls and maintaining compatibility (POSIX sh not bash), then yes, I like to think so. :) > Do you still love it? Oh yeah! I've been writing a ton of P…

Wow, very impressive. Do you also believe it's a viable language with which newcomers should start writing scripts? Edit: follow up question is Do you believe bash / POSIX shells actually follow KISS principles? Not questioning whether your OS is KISS, but I don't think that necessarily reflects the KISS-ness of the underlying language. My questions clearly reflect my current impression that in the long term, shell p…

> Do you believe bash / POSIX shells actually follow KISS principles?

POSIX `sh` yes. `bash` less so but I'd still lean more towards a yes.

Ultimately though, it depends on how we define "simple". Both `bash` (2.6MB) and POSIX `sh` shells (`dash` (232KB), `ash` (1.2MB (busybox)), etc) are tiny in size if we compare them to Python (137MB) or Perl (44MB).

(Numbers taken from my system using `du` on each file which belongs to each shell/language.)

If we define "simple" to language features then I think the shells come out on top again (especially POSIX `sh`).

If we define "simple" as ease of use (without shooting yourself in the foot) then I'd agree with you and say that the shell loses here.

There's a time and place for using any tool (in production) but I find it fun to push the shell beyond what is thought possible in my personal projects. :)

Re: Pure Bash Bible

#98

Post by james_s_tayler »

Tepix wrote: post #91
Jenz wrote: post #85

Looking at the very first example: trim_string(){ # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } This reads horrible. I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external programs/commands.

> This reads horrible. Just use the shell function by its descriptive name... The reasons are explained in the foreword: Calling an external process in bash is expensive and excessive use will cause a noticeable slowdown. Scripts and programs written using built-in methods (where applicable) will be faster, require fewer dependencies and afford a better understanding of the language itself.

The slow down caused to any developer that has to try and read that is probably orders of magnitude more worth optimizing for than how fast a bath script runs.

I'll take the grep/sed/awk version.

Re: Pure Bash Bible

#99

Post by Jenz »

Tepix wrote: post #91
Jenz wrote: post #85

Looking at the very first example: trim_string(){ # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } This reads horrible. I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external programs/commands.

> This reads horrible. Just use the shell function by its descriptive name... The reasons are explained in the foreword: Calling an external process in bash is expensive and excessive use will cause a noticeable slowdown. Scripts and programs written using built-in methods (where applicable) will be faster, require fewer dependencies and afford a better understanding of the language itself.

I was talking about the implementation. To whoever has implemented and who will maintain this; to them I think this will read horrible, and that is not good even if it is invisible to an end-user. I mean, how long wouldn’t even a very experienced bash programmer take to understand that substitution...

Re: Pure Bash Bible

#100

Post by rhizome31 »

Jenz wrote: post #99
Tepix wrote: post #91

Earlier quoted context omitted.

> This reads horrible. Just use the shell function by its descriptive name... The reasons are explained in the foreword: Calling an external process in bash is expensive and excessive use will cause a noticeable slowdown. Scripts and programs written using built-in methods (where applicable) will be faster, require fewer dependencies and afford a better understanding of the language itself.

I was talking about the implementation. To whoever has implemented and who will maintain this; to them I think this will read horrible, and that is not good even if it is invisible to an end-user. I mean, how long wouldn’t even a very experienced bash programmer take to understand that substitution...

To be fair this is one of the least readable examples of the document. They're not all that bad.
Post reply on HN