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

61–70 of 106 posts

Re: Pure Bash Bible (2018)

#61

Post by chasil »

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…

If you want floating point, run ksh93.

If you prefer rigid adherence to standards, use awk.

Re: Pure Bash Bible (2018)

#62

Post by jpc0 »

amelius wrote: post #40
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…

Yes. Can someone please write an LLM that can translate shell scripts to Python, for those cases when my shell script starts exceeding a screenful of lines.

To be fair for most of the shell scripts I write it would be more work to put it into an LLM and then verify what it output is correct than just retyping it in python.

I tend towards python these days if I need more than 1 variable since at that point I'm probably in the weeds already.

If it's just a ton of commands in succession though, I leave it bash. I have a few scripts in bash and PowerShell for weird ffmpeg operations I generally don't want to remember, stuff like loudness normalisation and converting to specific formats with specific parameters using ffmpeg.

Re: Pure Bash Bible (2018)

#63

Post by da39a3ee »

It's so tempting to implement in bash. I made the mistake _again_ this week! It's so seductive to be able to start subprocesses with no ceremony, use output redirection, use jq, etc.

If you have even the slightest hesitation regarding whether the task in front of you would be better done in a real programming language, the answer is do it in a real programming language.

Re: Pure Bash Bible (2018)

#64

Post by KolenCh »

gabrielgio wrote: post #58
dinkleberg wrote: post #20

Earlier quoted context omitted.

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?

> Why does it matter that some use AI tools as a starting point? I rather learn (or iterate) using a proper source of information (like a book, a blog post written by someone with actual knowledge, or even with a more experience coleague). At least for me it seems more productive.

Try pasting a piece of code you don't understand and ask LLM to explain it to you.

Then try the same and find a human to explain it to you.

Then compare the price (including money and time) and performance of both.

I won't believe you made an objective assessment if your conclusion is that either party is the best solution all the time. The point is right now the number of occasions that AI has better price performance is large enough for it to be generally useful.

Re: Pure Bash Bible (2018)

#65

Post by rascul »

jjice wrote: post #56

I always hear people talk about writing portable, POSIX compliant shell scripts so they'll work in more environments (assuming those environments are needed, of course), but how often do you run into an environment where you don't have a fairly complete version of Bash available? Genuine open question, I'd be really interested to know what that situation is. Lean container images, embedded, older systems? I'm really…

I put a recent bash everywhere I need to work. Not everyone can, though.

Re: Pure Bash Bible (2018)

#66

Post by chasil »

throw0101b wrote: post #44
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…

> 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.ubun…

One major reason that Debian chose dash is plainly written on the bash manual page:

  $ man bash | sed -n '/BUGS/,/^$/p'
  BUGS
       It's too big and too slow.
Another major reason is adherence to the POSIX standard; bash was written a decade prior to standardization, and has interesting issues because of this.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

Re: Pure Bash Bible (2018)

#67

Post by throw0101b »

chasil wrote: post #66
throw0101b wrote: post #44

Earlier quoted context omitted.

> 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.ubun…

One major reason that Debian chose dash is plainly written on the bash manual page: $ man bash | sed -n '/BUGS/,/^$/p' BUGS It's too big and too slow. Another major reason is adherence to the POSIX standard; bash was written a decade prior to standardization, and has interesting issues because of this. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

> bash was written a decade prior to standardization, and has interesting issues because of this.

bash can do whatever it wants to do if it's called as "bash". But it should only do specific things when called as "sh". This is true of any shell:

> When interpreted with dash instead of bash, the same script will fail. This is because dash is much stricter than bash in following the sh standard. Since dash is designed as a minimal implementation of the sh standard, it has to be stricter. The double brackets [[ … ]] are a ‘bashism,’ or a feature only available in bash and other, later shells such as ksh and zsh.

> Even though zsh also interprets most of these bashisms, zsh in sh compatibility mode is also stricter than bash and will error.

* https://scriptingosx.com/2020/06/about-bash-zsh-sh-and-dash-...

* https://zsh.sourceforge.io/Doc/Release/Invocation.html#Compa...

POSIX.2: Shell and Utilities (IEEE Std 1003.2-1992) is a few decades old now: regardless of when bash development started, I would think that by the 2010s it would have managed to better compartmentalize compatibility and extensions.

Re: Pure Bash Bible (2018)

#68

Post by pletnes »

jjice wrote: post #56

I always hear people talk about writing portable, POSIX compliant shell scripts so they'll work in more environments (assuming those environments are needed, of course), but how often do you run into an environment where you don't have a fairly complete version of Bash available? Genuine open question, I'd be really interested to know what that situation is. Lean container images, embedded, older systems? I'm really…

Containers/docker/kubernetes and embedded systems that use e.g busybox is what I’ve seen. Also macOS (used to?) ship ancient bash versions, but there’s recent zsh so that’s mostly fine.

Re: Pure Bash Bible (2018)

#69

Post by izzdrasil »

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…

One of the best shell skills you can have is knowing when to write it in another language.
Post reply on HN