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

81–90 of 258 posts

Re: Pure Bash Bible

#81

Post by jbrnh »

YawningAngel wrote: post #77
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.

But if I write the script for a bunch of RHEL servers then OS X and brew are irrelevant, and the full path is better (IMHO). It's the 'always use env..' I object to.

Re: Pure Bash Bible

#82

Post by al_form2000 »

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 is probably the closest but still has some warts related to redirection.

I wholehartedly agree on perl but can you expand on the redirection warts? I seldom had problems with perls' FHs, while, on the contrary I seem to be unable to wrap my head around the contorted syntax involved in bash's handling of descriptors - especially when more than 2 handles are involved.

Re: Pure Bash Bible

#83

Post by pxtail »

croo wrote: post #63

I write a bash script or two every month so I thought I'm okay. But then came along the very first example: trim_string() { # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } Ok, so the : is somehow a temporary variable... Then there is a variable starting at $ and you lost me :D Can someone break down that line for me? What the hell is going on…

And that's the problem with bash scipting - very quickly it gets very cryptic, difficult to follow and understand without knowing various "clever tricks" and gimmicks. This is all fine and dandy for personal usage but god forbid other developers might need to changes something inside this kind "clever" code.

Re: Pure Bash Bible

#84

Post by kamaal »

daitangio wrote: post #37
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 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 of legacy systems) was so non standardized that people were literally parsing through log files and non standard data formats to store/exchange a lot of things, this was when the internet was growing crazy year over year, systems needed to be built and put in place. This means you really need to have first class facilities to manipulate text. You needed regexes baked neatly into the language. You needed qw, you needed ``, you needed while, you needed binary file handling features, you needed string manipulation facilities that could help you drill through any text file you could imagine, you needed powerful functional programming features, you needed OO etc etc. And you needed to get this done under tough deadlines on slow machines. Remember Java being cross platform compliant was one of the biggest selling point of the day. Perl had this before Java.

I personally worked on building a store using rcs and perl, that could store versioned config files, almost like a document data base. The parsing facilities required for the application we did demanded nothing short of a tool like Perl.

Python, and also Java growing rapidly once the data exchange formats were reduced to mark up languages and JSON. Suddenly you could with a library what most Perl programmers were doing using their language powers.

Also look at the Human Genome Project and Perl usage there.

Re: Pure Bash Bible

#85

Post by Jenz »

Looking at the very first example:

  trim_string(){  
      # Usage: trim_string "   example   string    "
      : "${1#"${1%%[![:space:]]*}"}"
      : "${_%"${_##*[![:space:]]}"}"
      printf '%s\n' "$_"
  }
This reads horrible. I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external programs/commands.

Re: Pure Bash Bible

#86

Post by ImaCake »

pxtail wrote: post #83
croo wrote: post #63

I write a bash script or two every month so I thought I'm okay. But then came along the very first example: trim_string() { # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } Ok, so the : is somehow a temporary variable... Then there is a variable starting at $ and you lost me :D Can someone break down that line for me? What the hell is going on…

And that's the problem with bash scipting - very quickly it gets very cryptic, difficult to follow and understand without knowing various "clever tricks" and gimmicks. This is all fine and dandy for personal usage but god forbid other developers might need to changes something inside this kind "clever" code.

Bingo. I am a pretty casual level scripter. My programming is always just a means to an end (usually biology related) and I would much rather write easy to read code that takes 30 secs to run than whatever the pure bash thing in the parent post is.

Re: Pure Bash Bible

#87

Post by jgtrosh »

dyanaraps wrote: post #59
jgtrosh wrote: post #53

Earlier quoted context omitted.

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

> Have you read Bash Pitfalls[1]? I've read pretty much everything I could get my hands on regarding the shell (including the mentioned link) and I still love it. > Do you write truly correct Bash/POSIX code? If we define correct as passing shellcheck, avoiding all pitfalls and maintaining compatibility (POSIX sh not bash), then yes, I like to think so. :) > Do you still love it? Oh yeah! I've been writing a ton of P…

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 pitfalls largely undermine the benefits of its apparent simplicity. The gist would be for you to provide some way to change my mind. I guess the codebase you provide is a strong counter example; but you'll agree it doesn't reflect general usage of shell in the wild.

Edit 2: You know what, I just read your original comment again. I kind of retract my question since you do concede that it's an uphill battle and you love it in spite of its flaws. I guess that's cool (and I agree it's fun trying to write correct bash as a challenge) as long as you're in control of the code being produced, but my main impression remains that it's a bad language to publicize and its presence in most codebases inherently bears a strong cost.

Re: Pure Bash Bible

#88

Post by collyw »

Jenz wrote: post #85

Looking at the very first example: trim_string(){ # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } This reads horrible. I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external programs/commands.

> I see no reason to prefer this over programs like sed, bash is after all a shell, intended firstly for running external commands.

Are there systems that don't come with sed installed? (Some docker containers I have logged into don't seem to have less).

Re: Pure Bash Bible

#89

Post by hnlmorg »

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…

If you pardon the shameless self promotion; I'm working on something just like that:

https://github.com/lmorg/murex

It currently has:

* Proper error handling (eg try and catch blocks)

* unit testing and debugging frameworks to help with development and maintainability

* data-type aware, including complex types like how CSV, JSON and YAML are all handled as memory structures and thus the same tools can query any structured data format without understanding it's contents

* while still ostensibly working the same way as a traditional POSIX shell

There's also some work on improving the REPL experience too where I've included:

* automatic man page parsing for flags

* a "tool tip text" like hint line which tells you where commands reside on the fs, what it does, etc. Which is handy if you're trying to debug an existing commend.

* if you paste multiline text into the console you get offered a chance to preview the text before executing it (handy if, like me, you're pretty useless at copy/pasting content reliably)

* a package management system so you know exactly which functions and imported scripts are loaded from which sources (no more "where did that autocomplete suggestion / alias / etc get loaded from?"

There's a few other features like support for events and such like, but they're not yet documented.

The shell is currently beta but I've been using it as my daily driver for about 18 months now. There are still quite a few bugs, plenty of places where code needs to be rewritten for performance and lots of stuff isn't yet documented (though the documentation is pretty good already considering it's only me working on it). So don't expect a finished product. However I do think I'm at the stage where I'm ready for more users to have a play and I welcome PRs, issues raised, general comments and feedback, etc.

# end of shameless self promotion :D

Re: Pure Bash Bible

#90

Post by collyw »

daitangio wrote: post #37
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 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 do Python more or less full time these days, but bash replacements are the things that I get Perl out for. It has so much more syntactic sugar that makes them better than Python. Python is better for proper applications. Perl is better for one off scripts for manipulating the underlying system.
Post reply on HN