Live data from Hacker News

Bashing the Bash – Replacing Shell Scripts with Python

medium.com

41–45 of 45 posts

Re: Bashing the Bash – Replacing Shell Scripts with Python

#41
post #22
post #16

Earlier quoted context omitted.

The problem with Bash functions is that they aren't really functions -- more like subroutines. You can't even return a value from a Bash function (just a numeric status code). Most of the functions the author wrote wouldn't even be possible in Bash, if only because they utilize return values. So your suggestion that he "compare similar programming styles" is practically impossible without using implicit state-passing…

> You can't even return a value from a Bash function (just a numeric status code). You can print a textual result and store it in a variable, which is a pretty natural pattern in bash, e.g., set -e download_command () { if type wget >/dev/null 2>&1; then echo "wget -q -O-" elif type curl >/dev/null 2>&1; then echo "curl -sL" else echo "Error: curl or wget is required" >&2 exit 1 fi } download=$(download_command) publ…

I roughed out a LISP interpreter in Bash. Since I just stored s-expressions in bash variables and/or returned s-expressions with echo and/or parsed the parens to compute cdr or car, it was not a big success.

Re: Bashing the Bash – Replacing Shell Scripts with Python

#42

The key is knowing what to use where. Writing certain scripts in Bash is miles more efficient use of time than using python because it's "better". While it's certainly possible to write bad scripts in Bash like the example given, it's just as possible to write bad scripts in Python. All the time spent learning to do bash-like stuff in Python could just as well be spent learning to write better Bash. I think the reada…

I work with a couple people who insistently write shell scripts in Python. I know it's anecdotal, but to me, it's like the metaphor 'When all you have is a hammer, everything looks like a nail.' The scripts use functions liberally, but the code isn't DRY nor self-documented. Written in shell, it would take a fifth of the LOC because there's no need to use subprocess or Popen and parse the output. They're not the best…

As my last project developed, I moved it from simple bash scripts directly to (mostly) python utilities that had their own DSLs.. ansible, supervisord.. I expected to need to look into their source, but given the workarounds in docs and web searches that never seems to need to happen.

The resulting configuration is all configuration and not hardcoded paths mixed with Popen and random custom parsing..

I would consider custom python worse than writing bash with too much logic in the cases where you could just exit with a failure.

I think the question for your coworkers is what are they reinventing and why do they think a custom remake of it isn't a waste of everyone's time? Further, why do they think they will be more employable after making embarrassing custom internal tools? Compare that to knowing how popular tools work and perhaps contributing something small to one of them or at least being able to answer a question about them.

Re: Bashing the Bash – Replacing Shell Scripts with Python

#44
Here's what my take on the script would be in bash (albeit untested):

https://gist.github.com/binaryphile/3cf01870516d5fffafbc84a0...

Whoever wrote the initial bash script was clearly in a rush. I don't hold that against anyone, but it makes it poor fodder for an example of why bash is "bad". In particular, for the kind of task illustrated, it's a far better choice than python and I say that as a (formerly) unabashed pythonista.

It takes some time to get chops in bash, especially since there's no culture of developing shareable libraries, but it's no harder to learn bash via stackoverflow/google searches than it is to learn python. Use python when you need data structures and objects. Use bash to automate what you would normally do on the command line. Is that so hard?

Re: Bashing the Bash – Replacing Shell Scripts with Python

#45
There's nuance and opportunity for shell, Python, Ruby, C, etc. It's a good practice standardize on a couple of languages and treat executables as opaque processes with a limited, well-defined API/ABI. The advantage of scripting languages is reuse across scripts. There is a limited ability to reuse across shell scripts, but it's often somewhat awkward.
Post reply on HN