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

31–40 of 106 posts

Re: Pure Bash Bible (2018)

#31

Post by dredmorbius »

lnxg33k1 wrote: post #9

I bought it just few days ago find it helpful but also i wish there was more context / explanation around some black magic syntax

Definitely this.

If only to note, say, the section(s) of the Bash manpage or GNU Info Manual in which topics are discussed.

Taking the first-listed example, the '%%', '##', etc., substitutions are covered in Parameter Expansion.

I tend to go first to manpages, though I'm well aware that GNU deprecates these (exceedingly unwisely IMO) in favour of the Info Doc format (and its dedicated single-purpose reader). I'll note that the manpage alone renders to 120 pages (man bash | pr | less) onscreen, which is fairly formidable.

The PDF-formatted GNU bash manual (a fine format for a reference of this sort) runs 196 pages: https://www.gnu.org/software/bash/manual/bash.pdf>

Re: Pure Bash Bible (2018)

#32

Post by hereonout2 »

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…

For me this is is it, if you're stringing together a load of other command line tools then a large well structured shell script is perfectly fine.

A typical task in my day job is extracting metadata from and transcoding large AV archives, I always use a bash for this because I'm mainly stringing together tools like ffmpeg or sox, making directories, tempfiles, creating chesksum manifests, etc.

Also I typically do this on large CPU machines with many cores, I can parallelize operations in one line using xargs and a bash function. Doing stuff like this in python is actually a real pain in comparison.

Re: Pure Bash Bible (2018)

#33

Post by [deleted] »

ftaghn wrote: post #28
1vuio0pswjnm7 wrote: post #23

Earlier quoted context omitted.

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

[deleted]

Re: Pure Bash Bible (2018)

#34

Post by rollcat »

1vuio0pswjnm7 wrote: post #3

dash is significantly faster than bash and lighter weight, too. I added tab completion and use dash as interactive shell as well as scripting shell.

I would argue reaching for the shell to do your scripting is never a good idea, unless your problem is trivial to begin with (e.g. fits in less than a hundred lines of extremely readable and straightforward code). My rule of thumb is: "can I fit it in a one-liner?" - then I refactor it until it's readable, or otherwise use something else.

Once you need to do fancy array manipulation, hash tables, data structures, etc you're very likely much better off with Python, Perl, Ruby, Lua, Tcl, JS, or literally anything else. Notably, one or both of Python and Perl are available out of the box on Debian (and derivatives), macOS, most (all?) BSDs, and so on. Targeting Python 3.6+ will probably cover 99%+ of the systems you can find in the wild (e.g. Ubuntu 18.04 and newer).

I have also had some minor success using Go for that purpose. The toolchain can trivially cross-compile executables for ca 40 different OS/arch combinations; you need to consider the os/arch if you're running something different than Linux/x86-64 but that will again likely put you in the 1%. I'm working on some tooling to make this approach more straightforward.

Re: Pure Bash Bible (2018)

#35

Post by koolba »

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

Just wait till you learn about: set -euo pipefail

That should be line two of every bash script.

Re: Pure Bash Bible (2018)

#36

Post by worldsayshi »

koolba wrote: post #35
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

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?

Re: Pure Bash Bible (2018)

#37

Post by kjuulh »

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 engineers on the scripts, it becomes a complete mess. And even then it can become almost impossible to grok.

The way we develop infrastructure automation, ci, and developer tools is binaries first and foremost, then plugins for our infrastructure (also binaries, or libraries) and then some zsh on top to provide a nice developer experience.

But we've had to heavily scale back our use of zsh, it simply turned into a ball of mud, like all software that isn't maintainable, upgrade-able, or simple enough to parse.

This isn't a dig on zsh, bash etc, we've just found out that we can't maintain zsh as a product to supply to our engineers, and as such have to correct.

Re: Pure Bash Bible (2018)

#38

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #3

dash is significantly faster than bash and lighter weight, too. I added tab completion and use dash as interactive shell as well as scripting shell.

The scripts I write are relatively short and simple. Another reason I have no interest in bash. I have seen some enormous bash scripts.

Re: Pure Bash Bible (2018)

#39

Post by 1vuio0pswjnm7 »

ftaghn wrote: post #28
1vuio0pswjnm7 wrote: post #23

Earlier quoted context omitted.

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

Lua, C.

Re: Pure Bash Bible (2018)

#40

Post by amelius »

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.
Post reply on HN