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

111–120 of 258 posts

Re: Pure Bash Bible

#111

Post by Jenz »

rhizome31 wrote: post #102
james_s_tayler wrote: post #98

Earlier quoted context omitted.

The slow down caused to any developer that has to try and read that is probably orders of magnitude more worth optimizing for than how fast a bath script runs. I'll take the grep/sed/awk version.

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.

Re: Pure Bash Bible

#112

Post by unixhero »

lordfoo wrote: post #101
sumosudo wrote: post #62

Earlier quoted context omitted.

My favourite way to log.. Redirect stdout and stderr ( &> ) into a named pipe ( >() ) running "tee" And get the redirect into the log file as well. `exec &> >(tee ${__DIR}/${DOC_LOCAL}/${LOG_LOCAL})`

Would you mind expanding on this with an example? I'm trying to improve performance of my bash logging

+1. My goal is to learn how to robustly do any logging whatsoever. Eager to learn new tricks.

Re: Pure Bash Bible

#113

Post by CaptainZapp »

dyanaraps wrote: post #109
CaptainZapp wrote: post #107

Earlier quoted context omitted.

Just some feedback on the sale of the book (which I wanted and probably will buy). Upon checkout you need to confirm the sale via a email sent to the email address provided by you. I may be the exception and granted - it's basically due to a very crappy phone on which email ceased to work - but I was not able to finalize the sale since I'm not able to access my private email remotely. I sent myself the link and will…

I'll look into also putting the book on Amazon or another "ebook" website. I chose leanpub as it _is_ for books like this but if it does cause issues for people I'll explore my options on other platforms. Thanks for letting me know and apologies for the inconvenience.

It's more an annoyance than really a problem and stick with them rather than Amazon. Leanpub looks like a nice enough bunch and you, as the author, receive most of the proceeds.

I'm probably anyway the exception nowadays not being able to access private email remotely. But what you may point out to them is that it may be worthwhile to think through their checkout process. Also for their own benefit and the benefit of other authors

As I said I sent the link to myself and if I don't forget will buy it from home.

I really like to support you and your efforts and it looks like an awesome resource for somebody using bash a lot.

Re: Pure Bash Bible

#114

Post by letusnot »

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 recently started working a more devops role at a company (I've been a ruby dev for most of my career) and one of the things that I've noticed is how _insane_ scripting by ops people is. I'll start poking around a build pipeline and there will all sorts of tortured usages of sed and jq and bash and coreutils to get things done that would be _really_ simple in ruby. I routinely see people using wget and curl in the same script. I'll see people pipe sed text replacement into perl for more text replacement. I'm constantly aware of ruby three liners that are fully portable, even to Windows, that could replace a dozen lines of potentially subtly buggy shell scripting.

And honestly I can't see any good argument for this patchwork approach to gluing things together. I guess some ops people might argue that you'd have to have ruby everywhere but the counter argument would be that we use docker images for everything and adding ruby as a dependency isn't any worse than all the insane dependency gymnastics it takes to get our node apps working.

And all of this applies equally for any language with a reasonable standard library (python, perl). I think people have weird feelings about using bash or make or whatever to accomplish things, like they are riding closer to the metal or that they are living some deeply pragmatic zen Unix philosophy, but mostly they are making an un-testable mess until it works once and then, if they are lucky, they don't have to touch it again.

Re: Pure Bash Bible

#115

Post by collyw »

kamaal wrote: post #84
daitangio wrote: post #37

Earlier quoted context omitted.

I am slowing moving from bash to python for my utility script. I was unable to love Perl, I think this weired syntax is a very bad choice. Anyway bash is still faster to use, and a lot of Unix services are based on it. The book is well written and have a great added value. Thank you for sharing!!

>>I think this weired syntax is a very bad choice. Ah, the luxury the modern breed of programmers enjoy today makes me feel jealous. In these days of Splunk and Document databases(returning jsons and xmls) its hard to understand why so many things in the past were the way they were. Apart from DBMS interaction(Perl had DBI/x modules for that), pretty much every thing in the decade of 80's even upto late 2000's(tons o…

Perl's Tie::DBFile is still the lowest effort data persistence I have seen.

https://perldoc.perl.org/DB_File.html#A-Simple-Example

Re: Pure Bash Bible

#116

Post by james_s_tayler »

rhizome31 wrote: post #102
james_s_tayler wrote: post #98

Earlier quoted context omitted.

The slow down caused to any developer that has to try and read that is probably orders of magnitude more worth optimizing for than how fast a bath script runs. I'll take the grep/sed/awk version.

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.

Sure. I don't disagree there is a time and a place. I just never personally encounter those kinds of times or places. I don't doubt they exist and in that case I would definitely agree the correct way to address it would be write the more performant code.

I guess my bash uses cases are more just around internal tooling and are never performance critical, so my personal preferences are for readability under those circumstances.

Re: Pure Bash Bible

#117

Post by jmnicolas »

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' "$_"
  }

Re: Pure Bash Bible

#118

Post by hnarn »

dyanaraps wrote: post #93
hnarn wrote: post #67

Earlier quoted context omitted.

This might be an odd/off-topic question, but in Telegram this article has an auto-fetched thumbnail of a cat smoking a cigarette and a text similar to 'heavy metal music playing', I'm just curious where this picture is from, if you have any idea? I checked the README for the repo, pictures of the contributors etc. but I'm unable to figure out where it's coming from.

That's a very very very old GitHub avatar of mine, I wonder why Telegram hasn't pulled a later one.

Curious, thanks for the answer!

Re: Pure Bash Bible

#119

Post by lenkite »

dyanaraps wrote: post #97
jgtrosh wrote: post #87

Earlier quoted context omitted.

Wow, very impressive. Do you also believe it's a viable language with which newcomers should start writing scripts? Edit: follow up question is Do you believe bash / POSIX shells actually follow KISS principles? Not questioning whether your OS is KISS, but I don't think that necessarily reflects the KISS-ness of the underlying language. My questions clearly reflect my current impression that in the long term, shell p…

> Do you believe bash / POSIX shells actually follow KISS principles? POSIX `sh` yes. `bash` less so but I'd still lean more towards a yes. Ultimately though, it depends on how we define "simple". Both `bash` (2.6MB) and POSIX `sh` shells (`dash` (232KB), `ash` (1.2MB (busybox)), etc) are tiny in size if we compare them to Python (137MB) or Perl (44MB). (Numbers taken from my system using `du` on each file which belo…

Shell scripts also win "simple" in ease of deployment. (well assuming the author has paid attention to platform differences)

Re: Pure Bash Bible

#120

Post by marcosdumay »

lostmsu wrote: post #54
jigglesniggle wrote: post #21

Earlier quoted context omitted.

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…

So PowerShell then?

PowerShell removes the pomp from running processes and adds it squared into running normal functions.
Post reply on HN