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

201–210 of 258 posts

Re: Pure Bash Bible

#201

Post by jascii »

munk-a wrote: post #195
ulysses wrote: post #181

Earlier quoted context omitted.

"A collection of pure bash alternatives to external processes."

It is a neat academic exercise to find these but I think that's sort of the point - why? If you're building something that multiple folks will be reading and using just call out to external processes and make it easier to follow what's going on. It's neat to know how to do these things, but they're honestly a bit of a security hole because a large portion of folks using them will never comprehend the why and how and…

Why? No external dependencies, your code can run anywhere you have a Bash shell. This also means a smaller attack surface.

Also readability: While some of the examples may be somewhat confusing to someone who doesn't have a lot of Bash experience, to someone who does it can be a lot more readable then feeding a string in yet another language to an external program and processing the output..

Re: Pure Bash Bible

#202

Post by [deleted] »

jmnicolas wrote: post #117

I have a personal dislike for regexes and non human readable code, it gives maintenance headache. It's why I avoid shell scripts as much as possible. The first example is not human readable, if the name of the function is a lie, I have no idea what this piece of code do : trim_string() { : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" }

[deleted]

Re: Pure Bash Bible

#203

Post by jascii »

dec0dedab0de wrote: post #161
mankyd wrote: post #149

Earlier quoted context omitted.

My (personal) better recommendation is to avoid bash scripts whenever possible ;) I generally tell people that, once a script is longer than ~100 lines and/or you start adding functions, you're probably better off with something like Python. I know that's not a popular opinion with shell enthusiasts, but it's saved me so much frustration both in writing new scripts and coming back to them later for refactoring.

My rule of thumb is to use a real language if there is more than one if fi block.

So, what in your opinion constitutes a "real language", and why?

Re: Pure Bash Bible

#204

Post by [deleted] »

deschutes wrote: post #170
inimino wrote: post #126

Earlier quoted context omitted.

I have a personal dislike for "non human readable" used as shorthand for "not immediately and easily readable by me".

The human part is a hyperbole. "This code is unreadable" implies "This code is unreadable for the intended audience." Here's how I'd write that function: trim_string() { python3 -c 'import sys; sys.stdout.write(sys.argv[1].strip())' "$1" }

[deleted]

Re: Pure Bash Bible

#205

Post by rhizome31 »

Jenz wrote: post #111
rhizome31 wrote: post #102

Earlier quoted context omitted.

Not defending this particular example, but there are contexts where avoiding an external call can make a difference. Think a script calling an external program in a deeply nested loop. This sort of optimization could be used as a last resort, after identifying a real performance issue and evaluating the possibility of restructuring the code.

Would not the chances be, that if in a deeply nested loop, requiring optimization— you’re better of using a "proper" programming language? Maybe Python, or something similar.

Yes sure, but rewriting a legacy system is not always an option. My experience comes from the scientific computing world where venerable Fortran programs are glued together with huge piles of shell scripts.

Re: Pure Bash Bible

#206

Post by rhizome31 »

Jenz wrote: post #197
IronWolve wrote: post #186

Earlier quoted context omitted.

I've ran into this decades ago with file servers back. Half a million files, takes too long to do a simple for loop and calling 3rd party processes for awk/sed when I was just using them to format/search text. Breaking it down to just to mosty bash one scripts reduced the run time and ended all pauses.

I was going to argue that it would be better to simply not use a shell for that, but > decades ago Frankly, I can only imagine how the environment then would be. Thinking back with your current experience, what do you think you would have done if you had to fix it again?

And the funny thing is that some of these systems are still in use for critical missions.

Sometimes even bash isn't an option, you have to deal with older shells like ksh.

Re: Pure Bash Bible

#207

Post by tynorf »

cfors wrote: post #159
fsaintjacques wrote: post #156

Earlier quoted context omitted.

Python is a portability minefield. I'll spend more time trying to get the script/package run than reading the bash script.

Couldn't agree more, but honestly I think that is a completely overplayed issue. Just be explicit (This requires Python3.7) and have a requirements.txt file, maybe bundle with a `make install` command and move on. If people can't figure that out... I don't know how you're going to expect them to read a cryptic bash script. Don't get me wrong there is totally some good use cases for bash. Init-scripts come to mind whe…

> Just be explicit (This requires Python3.7)

Or just use a `#!/usr/bin/env python3.7` shebang.

Re: Pure Bash Bible

#208

Post by kazinator »

deschutes wrote: post #170
inimino wrote: post #126

Earlier quoted context omitted.

I have a personal dislike for "non human readable" used as shorthand for "not immediately and easily readable by me".

The human part is a hyperbole. "This code is unreadable" implies "This code is unreadable for the intended audience." Here's how I'd write that function: trim_string() { python3 -c 'import sys; sys.stdout.write(sys.argv[1].strip())' "$1" }

Problem: we're using trim_string in an initramfs image. Now we need Python3 in initramfs. Oops, kernel doesn't fit into the ARM board's flash partition any more ...

Re: Pure Bash Bible

#209

Post by clownpenis_fart »

deschutes wrote: post #170
inimino wrote: post #126

Earlier quoted context omitted.

I have a personal dislike for "non human readable" used as shorthand for "not immediately and easily readable by me".

The human part is a hyperbole. "This code is unreadable" implies "This code is unreadable for the intended audience." Here's how I'd write that function: trim_string() { python3 -c 'import sys; sys.stdout.write(sys.argv[1].strip())' "$1" }

lmao @ spinning up a python interpreter just to perform a trivial string operation

Re: Pure Bash Bible

#210

Post by scbrg »

akdor1154 wrote: post #71
tannhaeuser wrote: post #55

Earlier quoted context omitted.

You can add me to those interested in a pure POSIX shell bible. Whenever I'm about to write a moderately large script, I'm actively avoiding bashisms as they don't buy me much yet make my script unportable. But, given you've spent so much time on this subject, are there any bashisms that are truly essential and you don't want to live without?

set -o pipefail

That, and local variables. I avoid bash for the same reasons as GP, so I tend to (reluctantly) live without pipefail and work around the lack of local variables with subshells (which I assume has a performance impact - but hey).
Post reply on HN