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

Pure Bash Bible (2018)

github.com

Post reply on HN
Print view View original

41–50 of 106 posts

Re: Pure Bash Bible (2018)

#41

Post by nextaccountic »

softwaredoug wrote: post #24
bhaak wrote: 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 p…

> Bash doesn't even support floating point!

But bc (and dc) does, and shell authors deemed this was good enough.

And that's part of the problem with the "Unix philosophy"

Re: Pure Bash Bible (2018)

#42

Post by koolba »

worldsayshi wrote: post #36
koolba wrote: post #35

Earlier quoted context omitted.

Just wait till you learn about: set -euo pipefail That should be line two of every bash script.

The more I use bash the less I want to use it. So much UX weirdness. I feel like making the complaints people usually have with JavaScript. I like JavaScript. Because I'm good enough at it to ignore the bad parts. If I get good enough at bash, will it get better?

> If I get good enough at bash, will it get better?

Bash itself will not get better because you'll be stuck writing scripts targeting some ancient version to ensure wider compatibility.

It's still a powerful skill to develop. It's a sweet spot between a one-off shell pipeline and something that involves actual logic.

Bash scripts should not be used for their logic. Think of them as a way to document a series of commands that you do not want to manually type. That can be including long argument names, generating includes or classpaths, or generating log file names based on the current time.

A good rule of thumb is if your script involves any if-statement other than parameter validation or basic on-success-of-x-do-y, it probably should be in a real language.

Re: Pure Bash Bible (2018)

#43

Post by dizhn »

dinkleberg wrote: post #20
gabrielgio wrote: post #15

Earlier quoted context omitted.

What could go wrong? Use a technology that is notorious for outputting wrong information to write a script that is really hard to get it right and then later reviewed by someone that can’t really understand it. At this point just use something else.

You say that likes writing code doesn’t involve experimentation in general. You can’t trust the code that that Chatgpt gives you, but you also can’t trust the code that even you write until you test it. It is always an iterative process. Why does it matter that some use AI tools as a starting point?

Either it gives you so much that you never learn anything of use from those iterations or it gives you too little that you might as well write it from scratch (and get better quickly).

Re: Pure Bash Bible (2018)

#44

Post by throw0101b »

1vuio0pswjnm7 wrote: post #6
LucasLarson wrote: post #4

Earlier quoted context omitted.

The same amazing guy also published the Pure sh Bible: https://github.com/dylanaraps/pure-sh-bible

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…

> That's not dash, it's bash in POSIX compatibility mode.

I was under the impression that bash's POSIX mode was 'leaky': that a lot of non-POSIX stuff/extensions are available even though it's called as /bin/sh.

I know this caused a lot of our users issues when we upgraded Debian/Ubuntu during its switchover to dash. We told folks you could either rewrite those parts of the code or call /bin/bash.

* https://wiki.ubuntu.com/DashAsBinSh

* https://lwn.net/Articles/343924/

Re: Pure Bash Bible (2018)

#45

Post by throw0101b »

prmoustache wrote: post #10
1vuio0pswjnm7 wrote: post #6

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 people actually symlink /bin/dash to /bin/sh? That would be extremely stupid.

> That would be extremely stupid.

Why?

Re: Pure Bash Bible (2018)

#46

Post by softwaredoug »

nextaccountic wrote: post #41
softwaredoug wrote: post #24

Earlier quoted context omitted.

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 p…

> Bash doesn't even support floating point! But bc (and dc) does, and shell authors deemed this was good enough. And that's part of the problem with the "Unix philosophy"

Yeah every invocation of bc is a call to a command. So if you do it in a loop, its going to be very slow.

I had to do this once. It was so slow, I decided to use integers in kind of fixed-point math where I just multiply all the floats by 100 and work with ints.

zsh supports float though

Re: Pure Bash Bible (2018)

#47

Post by nerdponx »

kjuulh wrote: post #37

I like bash, zsh and other shell languages as well. However, unless you're really experienced, they shouldn't be the product you ship, whether that is internally or externally to you or your company. Shell languages is the final layer of configuration and customization you apply to the setup, it should almost never be the foundation of what you build. Especially for a company, unless you've got really, really skilled…

At least you've discovered Zsh and hopefully its significant improvements over Bash. The only Bash benefit is readarray/mapfile, Z Shell is better in just about every other way.

Re: Pure Bash Bible (2018)

#48

Post by nerdponx »

robbywashere_ wrote: post #17

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

Maybe this is a bit of a silly question, but what's the point?

I do think it would be a really fun project. But is there really a practical use for it? Bash is portable but not that portable if you want to care about version compatibility. I understand that it's not always possible to install a different interpreted language like Perl or Python. Maybe the use case is for platforms where you can't install other language interpreters and can't cross-compile a compiled language? It seems like a very specific situation.

Re: Pure Bash Bible (2018)

#49

Post by scns »

robbywashere_ wrote: post #17

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

Not what you asked for but there is Babashka for scripting in Clojure.

https://github.com/babashka/babashka

Re: Pure Bash Bible (2018)

#50

Post by LikesPwsh »

javier_e06 wrote: post #30

After years writing bash scripts I stumbled with this line... set -e Which forces the script to exit on first error. This line be in the bible as Genesis 1:1

The weird defaults are partly down to the different requirements of scripting vs interactive terminal use.

The defaults of bash make more sense for terminal use than scripting.

Powershell is a bit further towards the scripting end of the spectrum- part of why it annoys people coming from bash.

Compiled languages would be at the scripting end.

Post reply on HN