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

71–80 of 258 posts

Re: Pure Bash Bible

#71

Post by akdor1154 »

tannhaeuser wrote: post #55
dyanaraps wrote: post #18

Earlier quoted context omitted.

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…

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

Re: Pure Bash Bible

#73

Post by cannam »

iamnotacrook wrote: post #65
lostmsu wrote: post #54

Earlier quoted context omitted.

So PowerShell then?

Isn't that Windows only?

Not any more: https://github.com/PowerShell/PowerShell/releases/

I quite like Powershell on Windows, but I'm not sure I dare try it on Linux. I think it might make my head explode.

Re: Pure Bash Bible

#75

Post by jbrnh »

I don't quite get the recommendation to always use env bash over #!/bin/bash? If I use the full path, it is to get just that - the system's Bash. If it is missing or overruled in $PATH then I most likely don't want the script to run in the first place.

Re: Pure Bash Bible

#76

Post by wolfhumble »

jgtrosh wrote: post #53
dyanaraps wrote: post #23

Earlier quoted context omitted.

The shell is my favorite language and I really don't know why. It's definitely possible to write shell code which properly passes shellcheck's linter though it's an uphill battle to learn the ins and outs and _why_ X is wrong when Y is right. I even managed to write a full TUI file manager in bash! https://github.com/dylanaraps/fff I full understand that there are times when the shell should not be used and when othe…

Have you read Bash Pitfalls[1]? Do you write truly correct Bash/POSIX code? Do you still love it? [1]: https://mywiki.wooledge.org/BashPitfalls

From what I understand, the commenter is the author of 'Pure Bash Bible' :-) https://getkiss.org/pages/team/

Re: Pure Bash Bible

#77

Post by YawningAngel »

jbrnh wrote: post #75

I don't quite get the recommendation to always use env bash over #!/bin/bash? If I use the full path, it is to get just that - the system's Bash. If it is missing or overruled in $PATH then I most likely don't want the script to run in the first place.

'System bash' isn't a universal or clear concept. For example, if you're using Modern OS X, you likely have bash via brew or some other userspace package manager but no system bash. Presumably you (or at least, most people) would still like your scripts to run in this case.

Re: Pure Bash Bible

#78

Post by davidrm »

dyanaraps wrote: post #15

Hello, I'm the author of the Pure Bash Bible. Happy to answer any questions you may have. Here's an example of what bash is capable of: https://github.com/dylanaraps/fff/ (a TUI file manager written in bash)!

completely unrelated, it's so funny that i saw this comment, looked at your name and thought "hey, i know this guy!". it turns out i forked your dotfiles ages ago when i first started playing with i3. also neofetch is pretty cool!

Re: Pure Bash Bible

#79

Post by [deleted] »

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

[deleted]

Re: Pure Bash Bible

#80

Post by unionpivo »

kamaal wrote: post #32
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…

Inability to use tools like Perl and Emacs is the biggest reason why I have to often break the bad news to people that their week to month long projects(Typically in Python and Java) can likely be done if a few minutes to a day or two, if they knew how to Emacs or Perl well. Programmers take great pride in freeing accountants and ware house workers from drudgery. But seldom do we look at our work in the same way. In…

ehh, I agree that its usually faster do do stuff in perl than in python, but if someone spent weeks doing something in python, that could be done in few minutes of perl, python is not the problem. And would probebly take them weeks to do it in perl as well.

There are things you can do in line of perl that will take you 5 -10 min in python, but once program goes above one liners, difference is not that big.

And of course, if you learned vim instead of emacs, you would be even faster :))

Post reply on HN