Live data from Hacker News

Bashing the Bash – Replacing Shell Scripts with Python (2017)

medium.com

51–60 of 138 posts

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#51

I was hoping someone finally had a library or something to make python good at the things shell does well (mostly, running stuff and piping output around). If only. This really just reads like someone who doesn't know shell and does know python, but thinks the problem is the tool. They continually describe shell with phrases like "obscure and difficult-to-predict" while talking through things that are either obvious…

https://github.com/MoserMichael/subb

https://pypi.org/project/subb/

I wrote this to simplify just that for my own tools; the subprocess module that comes with the batteries has a very general interface, i think that it is a bit complex for a quick script.

My objective was to get an abstraction, for a one line process run and extraction of the result, similar to what we had in Perl5 with the system library function. https://perldoc.perl.org/functions/system

Also the shell is impractical, when it comes to slightly more complex programs. There is a limit on what you can do with pipes. Maybe that's the reason why perl is that flexible, as they tried to bridge both realms: Perl had to be useful as a replacement for the quick shell like script, and to be useful as a general purpose programming language.

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#52
OK, I'll bite... The author would complain about my python3 in the same way and conclude it would be better to write it in my Bash.

Without questioning the "why" of the script, sans my customary morning coffee, and without having tested the code below.

Maybe I'd do something like this.

For the small price of function invocation overhead, the nice benefit of doing it this way is that one can `source` the functions into one's Bash shell and use each one as a standalone Unix tool, complete with tabtab completion, pipelines etc.

  #!/usr/bin/env bash

  stop_app() {
      pkill ${1:?Fail. App name required.}
  }

  today() {
      date +%Y%m%d
  }

  analyse() {
      local analyser=${1:?Fail. Analyser script name required.}
      local out_dir=$(printf "results_%s" $(today))
      while yaml_file
      do local out_file="${out_dir}/summary_$(basename yaml_file).txt"
         python3 ${analyser} ${yaml_file} > ${out_file}
         printf "%s\n" ${out_file}
      done
  }

  exec_analytics() {
      local analyser=${1:?Fail. Analyser script name required.}
      local source_dir=${2:-"~/Documents/ExtFin-EFS/smoke/"}

      find ${source_dir} -type f -name *.yaml |
          sort -r |
          analyse ${analyser} |
          tail -1
  }

  update_current() {
      local latest_outfile=${1:?Fail. Provide latest output file.}
      ln -sf ${latest_outfile} "current.txt"
  }

And maybe one can invoke it like...

  stop_app "whatever_app" &&  (
      trap "rm -f /tmp/module_design_analytics_outfile" 0 HUP TERM PIPE INT
      if exec_analytics module_design_analytics.py |
              tail -1 > /tmp/module_design_analytics_outfile
      then update_current $(printf /tmp/module_design_analytics_outfile)
           echo "Done"
      else echo "Oops. Something went wrong."
      fi
      trap - 0 HUP TERM PIPE INT
  )

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#53
post #48

I was hoping someone finally had a library or something to make python good at the things shell does well (mostly, running stuff and piping output around). If only. This really just reads like someone who doesn't know shell and does know python, but thinks the problem is the tool. They continually describe shell with phrases like "obscure and difficult-to-predict" while talking through things that are either obvious…

> I was hoping someone finally had a library or something to make python good at the things shell does well (mostly, running stuff and piping output around). If only. Good news, they did! Even better news: it doesn't require python, it's cross platform, and supports an easy-to-read verbose style for scripts but a quick-to-write terse style for interactive usage. It's an absolute joy to use for nested data structures,…

What is Powershell

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#54
The only real alternatives to bash are shit-tier languages like python and perl.

I will never use a programming language which has significant white space, specially if I may have to view and edit the scripts in a remote terminal with vi.

I am also not too interested in using a programming language which looks the same before and after encryption: https://www.goodreads.com/quotes/tag/437174-perl-the-only-la...

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#55

I was hoping someone finally had a library or something to make python good at the things shell does well (mostly, running stuff and piping output around). If only. This really just reads like someone who doesn't know shell and does know python, but thinks the problem is the tool. They continually describe shell with phrases like "obscure and difficult-to-predict" while talking through things that are either obvious…

We had some problem, roughly, "run a tool on all YAML files in the directory" or something. The first attempt that led to a production outage:

(It is late, bash examples are approximate. Don't sweat the syntax.)

  the_tool *.yaml
There weren't any YAML files, so argv[1] was literally "*.yaml", which then wasn't found, leading to errors, etc.

  shopt -s nullglob
  the_tool *.yaml
(Don't even get me started on how there's shopt -s and set -o and WTF.)

There weren't any YAML files, so argc was == 0, which the program considered an error. Mea culpea, perhaps.

  AN_ARRAY=(*.yaml)
  if [[  ]]; then
    the_tool "${AN_ARRAY[@]}"
  fi
This failed, b/c bash can't represent an empty array! (And we run -u, as one must, if one wants reasonable behavior.)

So finally the contorted,

  AN_ARRAY=(*.yaml)
  if [[ "${AN_ARRAY+x}" = x &&  ]]; then
    the_tool "${AN_ARRAY[@]}"
  fi
To say "you're holding it wrong" is just folly. Bash is worthy of the same treatment that "A Fractal of Bad Design" gave PHP, and it has no place in anything that wants to call itself engineering.

Use it on the command line in your day to day, fine; but if it's getting automated, jump to at least Python.

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#57

I was hoping someone finally had a library or something to make python good at the things shell does well (mostly, running stuff and piping output around). If only. This really just reads like someone who doesn't know shell and does know python, but thinks the problem is the tool. They continually describe shell with phrases like "obscure and difficult-to-predict" while talking through things that are either obvious…

We had some problem, roughly, "run a tool on all YAML files in the directory" or something. The first attempt that led to a production outage: (It is late, bash examples are approximate. Don't sweat the syntax.) the_tool *.yaml There weren't any YAML files, so argv[1] was literally "*.yaml", which then wasn't found, leading to errors, etc. shopt -s nullglob the_tool *.yaml (Don't even get me started on how there's sh…

On the contrary, I am 100% open to suggestions that BASH sucks. (Personally, I would have picked the inadequacies of `set -e` as my favorite ... unfortunate aspect.) My objection was very narrow: this specific article does a poor job at saying why shell sucks, and a worse job still at presenting Python as a superior alternative. That's not to say that good reasons to use something else don't exist, and it's not even to say that Python can't be that alternative. (Your sibling comments suggesting xonsh and https://amoffat.github.io/sh/ paint a fairly compelling way to actually move to python without losing the advantages of shell, for instance.)

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#59
I have ksh scripts I wrote over 20 years ago on xenix, which still work today on bash or ksh. Meanwhile I have python apps that didn't make it a year.

Any particular version of Python is a saner choice, if you could pick one and freeze it retroactively for the last 20 years and for at least the next 20. But that is not how Python works. Python breaks every 11 minutes.

I would not write anything in Python that I cared the slightest bit about longevity or portability.

Maybe if we made a subset of python, locked down the syntax and feature set, discouraged any use of plugins or libraries in any fancy way that relies on any kind of repository or package manager system, and gave it a new name to distinguish it from normal python, maybe that would be an ok replacement for any of the shells.

But that is not happeing and don't even try to pretend like it could.

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#60

I have ksh scripts I wrote over 20 years ago on xenix, which still work today on bash or ksh. Meanwhile I have python apps that didn't make it a year. Any particular version of Python is a saner choice, if you could pick one and freeze it retroactively for the last 20 years and for at least the next 20. But that is not how Python works. Python breaks every 11 minutes. I would not write anything in Python that I cared…

Over the past decade I've been drifting towards doing more and more in bash that I'd've normally done one one language or another just because of this stability. Perl is another candidate if I need something more complicated, but I'm not as familiar with it so I don't really reach for it often.

Are there any other languages with the same stability that would also fill this niche?

Post reply on HN