4 ms·

Cue all the "when your program gets longer than one line you should consider using python" comments.

• metadat 4y ago
  100% sane advice on the "should" front, but I don't always follow the shoulds.. Bash is just too damn fast to whip things up in (even at the risk of endless footguns). Build up a pipeline of commands, translate into script, done. It's powerful and can scale if common conventions and good practices are used. For easier debugging I always add a simple flag along the lines of: if $1 = -v then set -x; shift Obviously shellscripts are a terrible or highly suspect idea when production-grade transactional integrity is critical, but in many cases the swiftness of shell development outweighs the cons when the goal is to Get Things Done. The shell is a pretty sweet interface.
  • cjvirtucio 4y ago
    it's so much easier to glue tools together with it. I'd end up writing more code if I had used python's subprocess package or ruby's IO package. as long as I don't need a complex data structure of some sort.
• js2 4y ago
  Last week I wrote a bash script that ended up being about 250 lines. It was mostly running other processes. For technical reasons, it needed to re-invoke itself a few times via sudo. When I was done I looked over it and thought: this is a nice piece of code right now. It's well documented. It's self contained. It passes my tests. I could maintain this code. But it made use of quite a few bash'isms: arrays and so forth. I wasn't confident in the ability of my colleagues to keep it in good state. So I rewrote it in Python. The Python version ended up being a little longer, but that was mostly due to formatting difference. The Python version in addition I could reformat with black and isort, I added type annotations so I could test it with mypy. (I had formatting the shell version with shfmt and checked it with shellcheck, but still.) The Python version is much easier to read, and I think will be more maintainable. I consider myself competent in both languages so it's a courtesy to my colleagues if nothing else to ship the Python version.
  • disgruntledphd2 4y ago
    I used to think this way, and still do to a large extent. Unfortunately, we still need bash to build software (docker containers for example) so there's a limit to how much bash we can get rid of, unfortunately.
    • js2 4y ago
      Of course, and I still use it in those places where it's required and relatively self contained, or frankly, if it just happens to be the best tool for the job which it sometimes is. But now that I can expect python3 to be available on the systems I care about, and with the fairly comfortable ergonomics of subprocess.run, I find myself using Python in places I would've previously used bash. A good heuristic is the moment a bash script needs to use curl + jq, it's time for python. Especially on macOS it's nice having things like plistlib so I can avoid `defaults` and `PlistBuddy`.
• aaaaaaaaaaab 4y ago
  Yawn… Python sucks for building processing pipelines. How many lines of Python code would you need to implement this? paste -d \\n <(foo …) <(bar …) | while read -r f && read -r b; do baz “$f” “$b” done Mind you, `foo` and `bar` run in parallel.
  • slt2021 4y ago
    replace bash one-liner with python? No, thanks replace 200+ bash script with multiple subroutines in python? yes
    • dmtroyer 4y ago
      as someone who is maintaining mountains of legacy bash, for all that is holy, yes. or Go. or Rust. anything.
  • idispatch 4y ago
    Mind you, before this goes to prod please add error handling and logging. What happens when bar fails? What about baz? Now, please rewrite this so your team mates can maintain and extend. Yawn, I’ll wait for the PR.
    • aaaaaaaaaaab 4y ago
      Gotcha, thanks for the feedback! We should also totally A/B test this! I'll make sure that this ties in with the quarterly OKRs, too! I hope I'll get promoted to E6 for that sweet 10% raise next cycle :fingers_crossed:
  • d0mine 4y ago
    Nothing stops you from calling bash from Python to combine bash pipelines (onelines) but if you must use Python for some reason, to run `baz` for each line in `foo` & `bar` output: from subprocess import Popen, PIPE, run with Popen('foo', stdout=PIPE) as foo, Popen('bar', stdout=PIPE) as bar: for f, b in zip(foo.stdout, bar.stdout): run(['baz', f, b]) (there is a slight difference in behaviour)
• bryanlarsen 4y ago
  If your primary consideration is that it's generally available on a random developer's machine, what are the options? IOW out of the box on OSX and the major Linux distributions, and readily available on Windows. Python is pretty safe, but your code would have to work with both 2 & 3 and not pull in any external dependencies. And recommended practices have changed so drastically on how to install Python over the years that a random dev could have theirs in a fairly weird state. Perl would work, but hacked-together Perl has the similar drawbacks to hacked-together Bash, especially when it's me doing the coding. Ruby has problems similar to Python. Make & awk have problems similar to Perl & Bash. Therefore my latest rust package contains bash scripts.
  • vaporup 4y ago
    TCL
    • bryanlarsen 4y ago
      That's not installed by default on Linux distributions that I'm aware of. Expect is an awesome tool though.
      • kevin_thibedeau 4y ago
        It's in the Python standard library. Tkinter is just a wrapper around Tcl.
• gpderetta 4y ago
  To be fair you can do a lot in a bash one liner.
  • dmtroyer 4y ago
    doesn’t mean you should, for the sake of the next person.
• vlunkr 4y ago
  My rule is when you start needing functions or arrays you should consider using something else. Bash is really neat and easy to get started with, but maintaining a large codebase is terrible.