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

41–50 of 258 posts

Re: Pure Bash Bible

#41

Post by acqq »

dyanaraps wrote: post #18
tannhaeuser wrote: post #9

Didn't realize at first that "pure" refers to features available in bash without calling out to external processes, when I would've thought purism in this context should refer to avoiding bashisms and writing portable (ksh, POSIX shell) scripts.

I understand your concerns about bash features and POSIX compatibility. The bash bible was written specifically to document the shell extensions bash implements. My focus for the past few months has been writing a Linux distribution (and its package manager/tooling) in POSIX sh. I've learned a lot of tricks and I'm very tempted to write a second "bible" with snippets that are supported in all POSIX shells. (I created…

> I've learned a lot of tricks and I'm very tempted to write a second "bible" with snippets that are supported in all POSIX shells.

That could be potentially even more interesting than a bash-specific one (as it is harder to get it right -- bash can be figured out out of the single reference, anything "portable" has many dependencies).

Re: Pure Bash Bible

#43

Post by davedx »

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…

I use nodejs. Sometimes it's a case of "go with what you know" rather than "use the best tool for the job". I have too many other things to do for me to bother learning yet another language just for command line scripting.

Re: Pure Bash Bible

#44

Post by sambe »

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…

The overhead of repeatedly launching subshells/processes to do simple operations can add up quickly, especially if it is happening in loops or in parallel. Yes, you shouldn't be using bash for performance, we all know that. But scripts often grow over time and suddenly are found to be slow/resource hogs. I have seen people demand that proper logging be added to a bash program and it then get minutes behind because of the overhead of all the processes called to do the logging. I was able to make that 10000x faster using pure bash.

As to why people like it: it often feels more natural when you are automating what you would type interactively. Unix pipes/coreutils/etc. also feel like a better fit when that automation is mostly about connecting other programs (it's the auxiliary stuff that you'd maybe want in pure bash). Reading the subprocess Python documentation does not exactly fill me with joy. I've heard libraries like Plumbum make it a bit neater - but then you have to ask why learn a bunch of new libraries when I already know bash? In the end it's about the best tool for the job. The danger with bash is going too far, especially if you don't actually know it very well.

Re: Pure Bash Bible

#45

Post by ThePadawan »

harry8 wrote: post #36
masklinn wrote: post #28

Earlier quoted context omitted.

I'm not sure what that's supposed to do, but subprocess provides these facilities, although definitely in a more verbose way. f = Popen('ls', stdout=PIPE).stdout f.read() f.close() alternatively given this exact behaviour: run('ls', stdout=PIPE).stdout

yeah sure subprocess.check_output(). If you ever dealt with much perl you know how much more pleasant and easy launching processes was in that language - like shell. Python is great, I'm not on the "bash python" wagon. Launching processes, getting the output, munging it and shoving it at another process is more fiddly and less natural in python. If you want to use that as evidence that I'm a garbage developer go ahea…

You might like the python "sh" library [0]. It's not perfect, but it sure does remove the visual noise around subprocess.

[0] https://amoffat.github.io/sh/

Re: Pure Bash Bible

#46

Post by kamaal »

jigglesniggle wrote: post #21
danielecook wrote: post #16

Earlier quoted context omitted.

I don’t think it’s pomp. Once I learned Unix pipes and the tools for manipulating data (sed awk cut etc), it just became much faster and easier than writing python scripts that do the same thing. You can literally connect the output of one process to the input of another with a single character. It’s much more complex in python. It also tends to be very portable.

I think you're reading my comment the wrong way: I meant to say that doing e.g. piping in Python is a lot of pointless work (pomp), as you agree. This is perhaps one big benefit but not one that is exclusive to a sh-like language. Instead I would like to see a language with strong flow control or metaprogramming capabilities take on processes as a first class citizen. Perl is probably the closest but still has some w…

Perl was literally born because Larry Wall reached the limits of what could be done with a combination of Shell + C + Unix utils.

In fact this is how Perl 1 looks: https://st.aticpan.org/source/RCLAMP/perl-1.0_16/

https://github.com/Perl/perl5/commit/8d063cd8450e59ea1c611a2...

Re: Pure Bash Bible

#47

Post by masklinn »

kamaal wrote: post #33
masklinn wrote: post #28

Earlier quoted context omitted.

I'm not sure what that's supposed to do, but subprocess provides these facilities, although definitely in a more verbose way. f = Popen('ls', stdout=PIPE).stdout f.read() f.close() alternatively given this exact behaviour: run('ls', stdout=PIPE).stdout

Doesn't scale well when you have to stitch more than two commands with pipes, which is a very common use case for Unix CLI utilities.

Don't see why it "doesn't scale well", the overhead is roughly constant: use the stdout of one program as the input of the next.

Re: Pure Bash Bible

#48

Post by laurieodgers »

kamaal wrote: post #33
masklinn wrote: post #28

Earlier quoted context omitted.

I'm not sure what that's supposed to do, but subprocess provides these facilities, although definitely in a more verbose way. f = Popen('ls', stdout=PIPE).stdout f.read() f.close() alternatively given this exact behaviour: run('ls', stdout=PIPE).stdout

Doesn't scale well when you have to stitch more than two commands with pipes, which is a very common use case for Unix CLI utilities.

I found this problem as well when doing a direct port including pipes from bash to python. It was the first iteration into python and I was lacking time to do a proper port into python native.

The python code to do piping ends up as longwinded and the plumbing of pipes ends up a massive headache so I wrote tidycmd to overcome that issue https://github.com/laurieodgers/tidycmd

Re: Pure Bash Bible

#49

Post by 0xdeadb00f »

dyanaraps wrote: post #18
tannhaeuser wrote: post #9

Didn't realize at first that "pure" refers to features available in bash without calling out to external processes, when I would've thought purism in this context should refer to avoiding bashisms and writing portable (ksh, POSIX shell) scripts.

I understand your concerns about bash features and POSIX compatibility. The bash bible was written specifically to document the shell extensions bash implements. My focus for the past few months has been writing a Linux distribution (and its package manager/tooling) in POSIX sh. I've learned a lot of tricks and I'm very tempted to write a second "bible" with snippets that are supported in all POSIX shells. (I created…

I'd be very interested in a POSIX sh version of this bash bible.

Re: Pure Bash Bible

#50

Post by unhammer »

sodaplayer wrote: post #12
buraequete wrote: post #2

I expected a tool on bash where you can access the pure "Bible" hallelujah.sh

On that note, does anyone have a favorite cli Bible reading program?

`apt search bible` gives lots of hits, though my favourite edition is unfortunately only available on tumblr: https://kingjamesprogramming.tumblr.com/
Post reply on HN