14 ms·

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

92 points by itamarst 5y ago

koobz 5y ago
For folks that like the idea of porting over shell scripts to python: https://plumbum.readthedocs.io/en/latest/ https://plumbum.readthedocs.io/en/latest/
ChrisGranger 5y ago
(2017) Previous discussion: https://news.ycombinator.com/item?id=14998213 https://news.ycombinator.com/item?id=14998213
- cf100clunk 5y ago
  As well as: https://news.ycombinator.com/item?id=21306346 https://news.ycombinator.com/item?id=21306346
softwarebeware 5y ago
I think this article is supposed to commend Python as a better choice than Bash? I think the author forgot to make a convincing argument for that, though. > The point of bash-bashing is to reduce use of the shell. That's a tautology. I get it, we're supposed to reduce the use of bash ... but why? > Without much real work, it’s easy to replace shell scripts with Python code. But you're writing the same thing again? There needs to be more reason than this. > The revised code is easier to read and maintain, runs a little faster, and can have a proper unit test suite. Three claims. Any data to support it? Some of the examples of "bash is bad" are also not convincing to me. Here's an example: > An example of a shell obscurity is the way the current working directory is set. The cd command is clear enough, but in the presence of sub-shells using (), can make it difficult to discern a stack of nested shell invocations and how the working directory changes when the sub-shells exit. So...why do you have "a stack of nested shell invocations" that all need to be working directory aware? And how would this be any better in Python? (It could be better in either Python or Bash but either one still requires the developer to avoid simple mistakes.) I don't know. I don't get it. I feel like the author had the unfortunate experience of knowing more Python than Bash and inheriting someone else's (who also didn't have much Bash experience) crappy Bash code.
- d0mine 5y ago
  bash is anti-bicycle: no matter how long you use, it trips you up. https://www.oilshell.org/why.html https://www.oilshell.org/why.html Shell is great for one liners to run commands, cancerous for anything more complex. Fabric combines the best of both worlds: shell for one liners, Python for more complex logic https://docs.fabfile.org/en/2.6/getting-started.html#addendum-the-fab-command-line-tool https://docs.fabfile.org/en/2.6/getting-started.html#addendu...
  - softwarebeware 5y ago
    In my experience, it trips me up no more than Python or Fabric do. I have used Fabric a lot too. At another job, we built all of our pipeline tooling in it. I somehow keep returning to Bash, though. I enjoy it.
    - deleted 5y ago
      [deleted]
  - digisign 5y ago
    Interesting, I used fabric many years ago but thought it had been deprecated. However, it still seems remote focused. Is that a problem for a shell replacement?
    - Nullabillity 5y ago
      As far as I understand, Invoke is pretty much local Fabric. Or rather, Fabric is a networking layer on top of Invoke.
      - digisign 5y ago
        Thanks, looks like it has some similarities with make, however doesn't skip things already built.
- Syzygies 5y ago
  I've written extensive programs in Haskell, and yet I also have many Bash scripts. I go back and forth. For the longest time I ignored Perl and just wrote scripts in C. Then I learned Perl, then Python. I prefer Ruby for no better reason than it's less boring. These scripting languages share a common strength: nested hash tables make everything easier. Still, I'd revert to Bash, explaining that if you can't accomplish the same thing with virtual text files in Bash you don't really understand Bash. Nevertheless, switching from Bash to Ruby is like taking off a heavy backpack after a long day hiking. Who needs a joint when the weight is off your shoulders?
egberts1 5y ago
Rock The Bash-Bah! (Sorry, Oingo Boingo)
- chanandler_bong 5y ago
  Oingo Boingo? You mean The Clash...
  - jdowner 5y ago
    Is that a clang based shell? ;p
    - kevin_thibedeau 5y ago
      OOP with a lisp.
superkuh 5y ago
Beware of Python devs writing Python shell scripts. They're used to using all the brand new (backwards incompatible) language features as soon as they come out. The vast majority have no consideration for a 10 year old PC running a 10 year old OS. The python3.x they write will not run. Bash, surprisingly, gets backwards incompatible language features too. But the vast majority of bash developers are writing for all computers, not just computers with software from the last 3 years. Python language could work if you stuck to an old target. But python culture is a problem and makes this very unlikely. What python is, and what python devs deal with, changes constantly. That doesn't work for shell scripts where stability is king.
- michaelcampbell 5y ago
  > The vast majority have no consideration for a 10 year old PC running a 10 year old OS. The python3.x they write will not run. Python3 is just under 14 years old.
  - yjftsjthsd-h 5y ago
    Yeah, but nobody's targeting Python 3.0; I think the point was that the Python crowd is likely to exclusively target current versions and lean on 3.6 and under being officially EOL.
  - zeroimpl 5y ago
    If you are running a 10-year old version of python 3, and you try and install some recently written python 3 application, it will never work - you'll be stuck in dependency hell, even getting pip to run may be a challenge due to outdated certs or TLS versions.
manifoldgeo 5y ago
I'm fully in favor of replacing shell scripts with Python3 scripts wherever possible. In fact that's part of my job. That being said, the author of this article is using confusing / wrong terminology to discuss bash. This article says that, "The [bash] shell isn't a complete programming language". While I agree that bash lacks any real data types besides strings, bash is a Turing-complete programming language[1], so it's theoretically possible to write _any_ program in bash that can be written in Python. It might be a hell of a lot uglier and lack things like imports, modules, etc., but it can be done. For example, there is an implementation of an HTTP daemon written purely in bash[2]. Once again-- terrible idea, but great execution. [1]: https://en.wikibooks.org/wiki/Bash_Shell_Scripting#A_few_notes_on_terminology https://en.wikibooks.org/wiki/Bash_Shell_Scripting#A_few_not... [2]: https://github.com/avleen/bashttpd https://github.com/avleen/bashttpd edit: added newline to separate references
- rascul 5y ago
  > For example, there is an implementation of an HTTP daemon written purely in bash[2]. Once again-- terrible idea, but great execution. It's not pure bash, as it relies on netcat or socat plus some other external programs (ls, tree, cat, date). There does exist a pure bash httpd though. It relies on a loadable builtin (from the bash tree though not built by default). https://github.com/dzove855/Bash-web-server https://github.com/dzove855/Bash-web-server
yjftsjthsd-h 5y ago
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 with experience or from context, and then write something different in python (i.e. something you could write in BASH that does something different) that's not less obscure but is only using python obscurity. > An example of a shell obscurity is the way the current working directory is set. The cd command is clear enough, but in the presence of sub-shells using (), can make it difficult to discern a stack of nested shell invocations and how the working directory changes when the sub-shells exit. Er... yeah? So you expect PWD to be a global and it was actually a local? Or more explicitly: > One of the shell’s ickier features is that variables tend to be global. There are some exceptions and caveats, however, that lead to shell scripts that are broken or behave inconsistently. That's not a shell feature, that's just how people frequently write it - you can make functions and declare your variables local if you want. I can easily write a python script with all my variables at the top, too.
- BeetleB 5y ago
  > 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. xonsh (https://xon.sh/ https://xon.sh/) Been using it for a few years now. It's worth it.
  - rvieira 5y ago
    Never heard of xonsh before and it looks really useful. Thanks.
  - emacs28 5y ago
    I haven't heard of xonsh either till now. After looking it over, it seems like a perfect integration of sh with Python. There's a good chance I'll give an honest shot at migrating from zsh to xonsh this week.
krnlpnc 5y ago
Depends on what you’re doing. I wouldn’t want to worry about python environment when dealing with OS post-install scripting for instance.
keithalewis 5y ago
More Lillipythonian flame baiting. Summoning the great dang.
qalmakka 5y ago
As much as I appreciate Python, I much rather use Perl as a replacement for complex shell scripts. Perl 5 is ubiquitous, it has been stable for the best part of the last 20 years and it's unbeatable for all those tasks that involve heavy text processing. Python is good for complex, structured applications, but shell scripts are not that. Shell scripts are glue, and there's arguably no better glue than Perl.
- m463 5y ago
  I am well versed in the shell, perl and python. I first learned the shell, and pretty much stuck to it conservatively avoiding bash extensions. Later, I learned perl (around version 4) my first impression of perl was annoyance. $foo = 123; seemed silly because there was a dollar sign on the left side of the assignment. and... $foo, @foo, $', $_, s/abc/def/; all the syntax seemed needlessly cryptic and reinforced the "perl is a write-only language" idea in my mind. But then something happened. At some point all of these idioms went away as I became fluent and could think in perl. Because there were many ways to do something in perl, I found that it become VERY easy to get an idea in my head out into working code. So perl was to me my most expressive language. But what I've noticed is that many people haven't overcome the syntax barrier and perl looks like line noise to them. More worrying is the fact that everyone can get their ideas into perl, but because people solve problems so differently their perl can be vastly different from what I am accustomed to. So a few years later I learned python. The indentation requirement was a minor annoyance, but that was quickly overcome by the consistency and visual structure it added. A more major annoyance was that many things were harder to implement in python. Regular expressions is a huge one - they are a major feature of perl and I had learned to use them liberally. Yet I persisted and with help from the many "batteries included" with python, I was easily writing portable maintainable scripts in python. And they were still readable after 6 months. Now I write only small shell scripts, and past a certain size all other scripting is in python. It's quite easy to write meaningful scripts in python. (I've pretty much lost my fluency in perl via python -- I fumble around now looking at or modifying perl scripts) by the way argparse is quite easily my favorite import in python. parser = argparse.ArgumentParser(argument_default=None) parser.add_argument('-d', '--debug', action='store_true', help='debug flag') parser.add_argument('-c', '--config', default="~/.config", help='config file name') arg = parser.parse_args() if arg.debug: print('config file: %s'%arg.config) ...
BeatQuestGames 5y ago
That's basically what I did with this project. https://github.com/Mylab6/PiBluetoothMidSetup https://github.com/Mylab6/PiBluetoothMidSetup Of course I could of done this in bash, but Python is just so much cleaner.
BooneJS 5y ago
In my experience, bash makes the simple things simple and the hard things (like complex pipelines, validating arguments, or “pure bash”) really hard. YMMV. Python makes everything medium difficulty which can be a big win depending on the size of automation required.
kortex 5y ago
I myself kind of went full circle. I started mostly python, then started to really embrace bash, mainly because I joined a company where everyone else used it a ton, got pretty decent at it. Even wrote basically a primitive container orchestrator in Bash because my PM didn't want to use anything "newfangled". Then I joined a startup at basically the ground floor, and it's almost entirely pure python, with some Makefiles to automate common operations. All that to say, I have a lot of experience with both paradigms. And frankly...bash kinda sucks as a programming language and environment. It's a footgun factory. Even when I was most fluent, I constantly had to deal with nested quotes, escaping, stringly types, empty variables, implicit behavior. Python's biggest weak point is definitely its packaging and dependency ecosystem... but it at least has one. Bash doesn't even have modules. And it's gotten MUCH better over the years, with pyproject.toml, poetry, actual version resolvers, pipx makes managing venvs for cli tools way easier. "but bash is everywhere" says many folks. yeah, and? There was a point in time where it wasn't. Python is seeing way more market penetration. Xonsh (python based shell) and plumbum (python library which makes pipe-operating and subprocessing easier) are both great.
chihuahua 5y ago
I once worked for a company that had a product which had a fairly complicated and time-consuming build process. Someone had written a distributed build process using the traditional CMD.exe shell scripting language. It was running multiple processes in parallel, and they communicated by writing and reading text files. Later they added PowerShell scripts. All in all, there were tens of thousands of lines of PS and BAT scripts. It was quite a nightmare. The team was supposed to maintain this mess. We decided to create a compiler that translated .BAT scripts to C#. The idea was that the C# code would be easier to understand and modify. I left before it was complete, so I'm not sure how that worked out. But last I heard, they were pleased that some parts of it now ran thousands of times faster.
noasaservice 5y ago
Im dealing with some python3 crap today on my main laptop. Primarily, because of a library I compiled and installed, I'm getting other nasty side effects form it. Primarily that protonvpn-cli isnt now running becasue of some broken library. I've never had bash break like that. Quirks, sure. But never this sort of brokenness.
- kafkaIncarnate 5y ago
  I had a similar problem with the YouTube plugin for Kodi recently. Turned out to be some weird Python 3.10 regression that took over a month to fix. For ProtonVPN you can also use the OpenVPN config files they provide to avoid any Python client issues. Ironically I have a Bash script written around that to generate individual ovpn files as needed from the zip for myself.
sigmonsays 5y ago
having a hard time being sold here. mkdir -p would create the directory without error. checking if a directory exists is trivial before creating it. Python throws an error if the path given to os.mkdir exists too. This article is way too long to digest, so i should stop now. Perhaps the argument should be, rewrite hacky things in bash as programs and build them into your apps?
- rstuart4133 5y ago
  I've written a lot of bash scripts in my time, even some 10,000 liners. Christ - I have probably written over 100k lines of them. The big ones (by big I mean say over 100 lines) all started life when I thought they would remain under 100 lines. I'm a professional programmer by trade. Admitting to starting a program I know would be over 100 lines in shell script would be close to an admission of incompetence, because technically shell script is one of the worst computer languages out there. So I'd never admit to it. But it's so damned portable, and ubiquitous and the batteries it comes with (the 'nix cli tools) are to powerful and complete, it makes irresistible at times. Where this article falls down is they are recommending Python3. Python2 would be fine. But in 'nix environments, where file names and configuration files can't be treated as text (Unicode) because there is no well defined system encoding, Python3 manages to introduce more rare bugs than shell script. It encourages you to treat everything a text, the dies ignominiously when decoding the 'nix byte stream (file name or whatever) fails. (On Windows where everything is UTF16, this isn't a problem - for local files. It remains a problem for data from external systems, like the internet.) Pull off making a programming language less reliable than shell was a mean achievement - but the Python3 devs did it. Hats off to 'em.
- rawoke083600 5y ago
  >This article is way too long to digest, so i should stop now. Lol one of the top problems with having "scripts" in python, their reliability-lifetime" (a.k.a as execute-and-forget) is very limited. Packages are outdated, api changes etc etc
readingnews 5y ago
I have some bad news for you, from a long, long, long time CS/EE/Sysadmin person: I can probably run my bash script on every linux I ever touched. I can probably have that python code break on half of the linux boxen I use. This one does not have module X installed. This one is too old, this one is too new, this python is not holding its mouth just at the right angle to work. Yeah, bash bash all you want. I have pulled out scripts decades old and run them. I can not say the same for other things I have written.
- drewcoo 5y ago
  But which one is more likely to also run on Windows? /s
  - yjftsjthsd-h 5y ago
    ... Hilariously, I think shell might actually win that; neither is installed by default, but you get some sort of bash/sh with any of interix, WSL1/2, git, cygwin, or mingw.
    - DyslexicAtheist 5y ago
      isn't WSL like a hypervisor that runs a guest? I'm clueless about Windows but when I start a WSL it is usually some form of Debian or Ubuntu that I can download from the Microsoft "store". Therefore isn't the shell you have whatever comes with that guest?
- rawoke083600 5y ago
  >I can probably run my bash script on every linux I ever touched. Exactly THIS !
  - DyslexicAtheist 5y ago
    yeah python (and before perl with cpan) had these issues that maintaining a consistent system is more effort than writing the damn thing in the first place. I loved Perl but tried to avoid modules like the plague. And python is almost worse because the same mentality (avoid modules) was abandoned by most of the community so now you get incompatibilities with what the OS provides and what gets installed via pip. Perhaps it's unfair to pick at python for this when many of these issues are not the language but because people picking python when they should have just used shell script.
jrm4 5y ago
This feels like: "Moving furniture by throwing it in the back of a pickup truck is obviously bad. Here's how to do it with a forklift and 18-wheeler instead, because this is definitely better."
vonseel 5y ago
Places that I've implemented shell/utility scripts in Python tend to do so because their other application code was also in Python and Python has much more testing support than bash scripts will ever have. That's why I've done it before, to write tools like custom log rotating / clean-up stuff; another project that comes to mind was a data pipeline that used some Python regex stuff to clean up non-printable characters and ugly stuff from text files before importing data. Both of these projects had lots of tests to verify that the code did what we wanted it to do.
drewcoo 5y ago
I think some of the examples of Python being better are places you just shouldn't use Bash. Like testing (Bats sucks). Like string manipulation (use other utils or even languages callable from Bash). Like complicated logic. Just don't do that in Bash. Bash is for (glorified) one-liners. And for I-can't-believe-you-did-that-in-Bash-ers.
emacs28 5y ago
I decided a while ago to write all my future scripts in Python whenever possible instead of sh or bash due to the overall better syntax and power of Python. Typer is one of the better packages for running Python scripts from CLI. Fabric & Invoke are pretty good too. To run any bash commands in Python I have a Python script that creates a temporary bash file with the code to execute, makes it executable, runs it with the commands in the built-in subprocess package, then deletes the file. This makes any complex bash commands with piping and whatnot runnable straight from Python. This way I don't have to learn all the different bash-based Python commands from pathlib and whatnot that throw unexpected errors, and I can run them using pure bash syntax from Python. But then you also get all the benefits of Python's looping syntax, classes etc.
lawwantsin17 5y ago
adityaathalye 5y ago
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 )
ComradePhil 5y ago
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-language-that-looks-the-same-before?utf8=%E2%9C%93&id= https://www.goodreads.com/quotes/tag/437174-perl-the-only-la...
ms4720 5y ago
TCL would be a better choice, more so back then.
deleted 5y ago
[deleted]
Brian_K_White 5y ago
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.
- kafkaIncarnate 5y ago
  That's what Python2.7 is and why every major proprietary product won't adopt anything else. It's also why it won't go away. All of my Python 2.6-2.7 scripts haven't been touched in 10 years in production and they aren't likely to ever be updated. I actually now refuse to write new Python that isn't compatible with both 2&3 for this reason. Python3 refuses to stabilize.
  - fiddlerwoaroof 5y ago
    I’ve been slowly embracing the mantra “only use unmaintained software”: maintenance is great when it’s fixing bugs and such, but eventually people insist on breaking backwards compatibility.
    - Brian_K_White 5y ago
      That is a captivating idea!
    - kafkaIncarnate 5y ago
      Python2.7 is still maintained. If you mean my software I mentioned if something breaks I'm still required to fix it. I just doubt that will happen at this point and have other tasks to do.
gorgoiler 5y ago
The one thing about Python that makes it so much more compelling over Bash is that thing you discover you need once your script starts getting long and repetitive: functions, with arguments, and return values. Python does this much better than Bash. It’s the one thing that makes me no longer use Bash. Oh and exceptions. Exceptions! The TWO things about Python that make it more compelling are functions and exceptions. You stand a chance of handling errors in Python. In bash there’s very little else you can do, when encountering an exceptional situation that is an error, except stop. The nice thing about all these functions is you can put them in modules as well. Modules! Of course! A namespaced way of laying out non trivial amounts of code! Ok so real functions, exceptions, modules. Three things that makes Python my default tool of choice. And libraries. Bash doesn’t have pip. Sure, bash’s “pip” is the commands it can run aka /usr/bin, but if that’s your interface then it’s hardly as flexible as say gitlab.py or requests.py. So: apart from the functions, exceptions, modules, libraries. And speed. SPEED! And code formatting. And a debugger. And stack traces. …what has Python ever given us that makes it a no brainer replacement for bash scripts? “Brought Unicode” ”Unicode! Oh shut up!” — After MP
- cuteboy19 5y ago
  Typically you don't want to do dependency management for simple scripts, but that's fine because python is batteries included
- DyslexicAtheist 5y ago
  > And speed. SPEED! Maybe I'm just a terrible python programmer and also all those around me suck at it but in 20+ years I have yet to see a well optimized python script faster than a well optimized bash/ash/csh/ksh/zsh script. Maybe your point is true if a script constantly does foo=`some thing` and constantly shells out other commands.
  - gorgoiler 5y ago
    I was thinking of the time I calculated IPV6 EUI64 suffixes in bash for a kind of janky IPAM thing, and how even the barest minimum of arithmetic turned “instantaneous” into “takes seconds”. The bash-centric solution was to write a little eui64.c and call that from the script. Bash isn’t for doing things, it’s for making other programs do things. That worked fine for a bit, but in the end it just became easier to factor and reason about the project when it wasn’t a weird mixture of clever things, and one Pythonic lump of boring and predictable things.
rawoke083600 5y ago
Yo - I'm sure there are advantages, but "that python ecosystem" ! Bash is usually everywhere even on "new installations". I'd hate to fight package compatibility, virtual environments etc.. YMMV
liendolucas 5y ago
I didn't even read the article. The reason is that it depends what you need to do, from there you should decide what's the best tool to solve something. Recently I've started to automate all the package installations and configurations for some of the machines I have. I can't even imagine doing that in Python despite I've been using Python for a long time. I don't know that much about bash, but I got everything I needed and expected from bash scripts for the task I needed to do. Yes, there are moments when you try to solve something in bash that you think is trivial in other languages but with bash is painful. Few days ago tried to test if a value is present in a bash array using a function. Couldn't get it working after trying few things. Then I realized I could perform a very similar (and good enough) check just seeing if a directory and a file do exist in my relative path to the script I was running: `if [-d DIR ] && [ -f FILE ]; then ...`. So I needed to change my mindset a bit. Another example of where bash is really good is for tiny small tasks: I wrote a small script to increase/decrease volume that is coupled in i3 and calls the `mixer` command in FreeBSD. Works perfectly and never touched once it was working. Another one: I get an acoustic alert when my battery drops down below certain percentage. And a couple more: set a random background every time I log in to i3, download a page for offline reading. Again, doing any of these things (or similar ones) with something different than bash (or maybe your favorite shell lang) seems like picking up the wrong tool for the job. There was a time when I cursed shell scripting a lot and that was because I couldn't see when to use shell scripting. EDIT: Paragraph spacing.
rawoke083600 5y ago
I guess, if you really want a "coding-lang" rather than "just" bash. I'd give Golang a try, just because of the static-binaries. No environment issues or missing and clashing libraries. PS. I'd still go for bash 99/100.
vermaden 5y ago
Showing the code as images instead of text and not even with a fixed width font for code ... and I am suppose to trust that person? :)
MichaelMoser123 5y ago
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. https://github.com/MoserMichael/subb https://github.com/MoserMichael/subb https://pypi.org/project/subb/ https://pypi.org/project/subb/ Python doesn't have the problem of shell scripting language, it doesn't get impractical, as the program is getting more complex. In bash you have arrays, and even maps, but these aren't pretty. Also the shell scripting language is being evaluated by an parse tree/AST interpreter, that's significantly slower than even python, in it's byte code interpreted form. 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 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.
- deleted 5y ago
  [deleted]
mannykannot 5y ago
I agree with the general thesis that Bash is unsuited for production work of any complexity, but the coverage of pipelines is incomplete. The only two examples I have found (the examples are images, so I may have missed something) may be implemented in Python by calling sorted(), which is not the case in general. I feel it would be more persuasive if it had at least one example of setting up and running a pipeline.
sqqqqrly 5y ago
I love to write Makefile recipes that wrap bash into small make commands. My make boilerplate generates help from comments in the make file. I get completions for free. I want all make vars and some internal make recipes to not complete, so I prepend the name with an underscore. Make is great because it handles errors and dependency trees.
hulitu 5y ago
> Without much real work, it’s easy to replace shell scripts with Python code. The revised code is easier to read and maintain, runs a little faster, and can have a proper unit test suite. And give a wonderful syntax error.
conquistadog 5y ago
I've spent many years becoming quite fluent in bash. It's not trivial. But all objections here are surmountable if not outright features. Python is the right tool for many jobs. But so is bash, for someone willing to truly learn it.

92 points by itamarst 5y ago

For folks that like the idea of porting over shell scripts to python: https://plumbum.readthedocs.io/en/latest/ https://plumbum.readthedocs.io/en/latest/

ChrisGranger 5y ago

(2017) Previous discussion: https://news.ycombinator.com/item?id=14998213 https://news.ycombinator.com/item?id=14998213

cf100clunk 5y ago
As well as: https://news.ycombinator.com/item?id=21306346 https://news.ycombinator.com/item?id=21306346

softwarebeware 5y ago

I think this article is supposed to commend Python as a better choice than Bash? I think the author forgot to make a convincing argument for that, though. > The point of bash-bashing is to reduce use of the shell. That's a tautology. I get it, we're supposed to reduce the use of bash ... but why? > Without much real work, it’s easy to replace shell scripts with Python code. But you're writing the same thing again? There needs to be more reason than this. > The revised code is easier to read and maintain, runs a little faster, and can have a proper unit test suite. Three claims. Any data to support it? Some of the examples of "bash is bad" are also not convincing to me. Here's an example: > An example of a shell obscurity is the way the current working directory is set. The cd command is clear enough, but in the presence of sub-shells using (), can make it difficult to discern a stack of nested shell invocations and how the working directory changes when the sub-shells exit. So...why do you have "a stack of nested shell invocations" that all need to be working directory aware? And how would this be any better in Python? (It could be better in either Python or Bash but either one still requires the developer to avoid simple mistakes.) I don't know. I don't get it. I feel like the author had the unfortunate experience of knowing more Python than Bash and inheriting someone else's (who also didn't have much Bash experience) crappy Bash code.

d0mine 5y ago
bash is anti-bicycle: no matter how long you use, it trips you up. https://www.oilshell.org/why.html https://www.oilshell.org/why.html Shell is great for one liners to run commands, cancerous for anything more complex. Fabric combines the best of both worlds: shell for one liners, Python for more complex logic https://docs.fabfile.org/en/2.6/getting-started.html#addendum-the-fab-command-line-tool https://docs.fabfile.org/en/2.6/getting-started.html#addendu...
- softwarebeware 5y ago
  In my experience, it trips me up no more than Python or Fabric do. I have used Fabric a lot too. At another job, we built all of our pipeline tooling in it. I somehow keep returning to Bash, though. I enjoy it.
  - deleted 5y ago
    [deleted]
- digisign 5y ago
  Interesting, I used fabric many years ago but thought it had been deprecated. However, it still seems remote focused. Is that a problem for a shell replacement?
  - Nullabillity 5y ago
    As far as I understand, Invoke is pretty much local Fabric. Or rather, Fabric is a networking layer on top of Invoke.
    - digisign 5y ago
      Thanks, looks like it has some similarities with make, however doesn't skip things already built.
Syzygies 5y ago
I've written extensive programs in Haskell, and yet I also have many Bash scripts. I go back and forth. For the longest time I ignored Perl and just wrote scripts in C. Then I learned Perl, then Python. I prefer Ruby for no better reason than it's less boring. These scripting languages share a common strength: nested hash tables make everything easier. Still, I'd revert to Bash, explaining that if you can't accomplish the same thing with virtual text files in Bash you don't really understand Bash. Nevertheless, switching from Bash to Ruby is like taking off a heavy backpack after a long day hiking. Who needs a joint when the weight is off your shoulders?

egberts1 5y ago

Rock The Bash-Bah! (Sorry, Oingo Boingo)

chanandler_bong 5y ago
Oingo Boingo? You mean The Clash...
- jdowner 5y ago
  Is that a clang based shell? ;p
  - kevin_thibedeau 5y ago
    OOP with a lisp.

superkuh 5y ago

Beware of Python devs writing Python shell scripts. They're used to using all the brand new (backwards incompatible) language features as soon as they come out. The vast majority have no consideration for a 10 year old PC running a 10 year old OS. The python3.x they write will not run. Bash, surprisingly, gets backwards incompatible language features too. But the vast majority of bash developers are writing for all computers, not just computers with software from the last 3 years. Python language could work if you stuck to an old target. But python culture is a problem and makes this very unlikely. What python is, and what python devs deal with, changes constantly. That doesn't work for shell scripts where stability is king.

michaelcampbell 5y ago
> The vast majority have no consideration for a 10 year old PC running a 10 year old OS. The python3.x they write will not run. Python3 is just under 14 years old.
- yjftsjthsd-h 5y ago
  Yeah, but nobody's targeting Python 3.0; I think the point was that the Python crowd is likely to exclusively target current versions and lean on 3.6 and under being officially EOL.
- zeroimpl 5y ago
  If you are running a 10-year old version of python 3, and you try and install some recently written python 3 application, it will never work - you'll be stuck in dependency hell, even getting pip to run may be a challenge due to outdated certs or TLS versions.

manifoldgeo 5y ago

I'm fully in favor of replacing shell scripts with Python3 scripts wherever possible. In fact that's part of my job. That being said, the author of this article is using confusing / wrong terminology to discuss bash. This article says that, "The [bash] shell isn't a complete programming language". While I agree that bash lacks any real data types besides strings, bash is a Turing-complete programming language[1], so it's theoretically possible to write _any_ program in bash that can be written in Python. It might be a hell of a lot uglier and lack things like imports, modules, etc., but it can be done. For example, there is an implementation of an HTTP daemon written purely in bash[2]. Once again-- terrible idea, but great execution. [1]: https://en.wikibooks.org/wiki/Bash_Shell_Scripting#A_few_notes_on_terminology https://en.wikibooks.org/wiki/Bash_Shell_Scripting#A_few_not... [2]: https://github.com/avleen/bashttpd https://github.com/avleen/bashttpd edit: added newline to separate references

rascul 5y ago
> For example, there is an implementation of an HTTP daemon written purely in bash[2]. Once again-- terrible idea, but great execution. It's not pure bash, as it relies on netcat or socat plus some other external programs (ls, tree, cat, date). There does exist a pure bash httpd though. It relies on a loadable builtin (from the bash tree though not built by default). https://github.com/dzove855/Bash-web-server https://github.com/dzove855/Bash-web-server

yjftsjthsd-h 5y ago

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 with experience or from context, and then write something different in python (i.e. something you could write in BASH that does something different) that's not less obscure but is only using python obscurity. > An example of a shell obscurity is the way the current working directory is set. The cd command is clear enough, but in the presence of sub-shells using (), can make it difficult to discern a stack of nested shell invocations and how the working directory changes when the sub-shells exit. Er... yeah? So you expect PWD to be a global and it was actually a local? Or more explicitly: > One of the shell’s ickier features is that variables tend to be global. There are some exceptions and caveats, however, that lead to shell scripts that are broken or behave inconsistently. That's not a shell feature, that's just how people frequently write it - you can make functions and declare your variables local if you want. I can easily write a python script with all my variables at the top, too.

BeetleB 5y ago
> 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. xonsh (https://xon.sh/ https://xon.sh/) Been using it for a few years now. It's worth it.
- rvieira 5y ago
  Never heard of xonsh before and it looks really useful. Thanks.
- emacs28 5y ago
  I haven't heard of xonsh either till now. After looking it over, it seems like a perfect integration of sh with Python. There's a good chance I'll give an honest shot at migrating from zsh to xonsh this week.

krnlpnc 5y ago

Depends on what you’re doing. I wouldn’t want to worry about python environment when dealing with OS post-install scripting for instance.

keithalewis 5y ago

More Lillipythonian flame baiting. Summoning the great dang.

qalmakka 5y ago

As much as I appreciate Python, I much rather use Perl as a replacement for complex shell scripts. Perl 5 is ubiquitous, it has been stable for the best part of the last 20 years and it's unbeatable for all those tasks that involve heavy text processing. Python is good for complex, structured applications, but shell scripts are not that. Shell scripts are glue, and there's arguably no better glue than Perl.

m463 5y ago
I am well versed in the shell, perl and python. I first learned the shell, and pretty much stuck to it conservatively avoiding bash extensions. Later, I learned perl (around version 4) my first impression of perl was annoyance. $foo = 123; seemed silly because there was a dollar sign on the left side of the assignment. and... $foo, @foo, $', $_, s/abc/def/; all the syntax seemed needlessly cryptic and reinforced the "perl is a write-only language" idea in my mind. But then something happened. At some point all of these idioms went away as I became fluent and could think in perl. Because there were many ways to do something in perl, I found that it become VERY easy to get an idea in my head out into working code. So perl was to me my most expressive language. But what I've noticed is that many people haven't overcome the syntax barrier and perl looks like line noise to them. More worrying is the fact that everyone can get their ideas into perl, but because people solve problems so differently their perl can be vastly different from what I am accustomed to. So a few years later I learned python. The indentation requirement was a minor annoyance, but that was quickly overcome by the consistency and visual structure it added. A more major annoyance was that many things were harder to implement in python. Regular expressions is a huge one - they are a major feature of perl and I had learned to use them liberally. Yet I persisted and with help from the many "batteries included" with python, I was easily writing portable maintainable scripts in python. And they were still readable after 6 months. Now I write only small shell scripts, and past a certain size all other scripting is in python. It's quite easy to write meaningful scripts in python. (I've pretty much lost my fluency in perl via python -- I fumble around now looking at or modifying perl scripts) by the way argparse is quite easily my favorite import in python. parser = argparse.ArgumentParser(argument_default=None) parser.add_argument('-d', '--debug', action='store_true', help='debug flag') parser.add_argument('-c', '--config', default="~/.config", help='config file name') arg = parser.parse_args() if arg.debug: print('config file: %s'%arg.config) ...

BeatQuestGames 5y ago

That's basically what I did with this project. https://github.com/Mylab6/PiBluetoothMidSetup https://github.com/Mylab6/PiBluetoothMidSetup Of course I could of done this in bash, but Python is just so much cleaner.

BooneJS 5y ago

In my experience, bash makes the simple things simple and the hard things (like complex pipelines, validating arguments, or “pure bash”) really hard. YMMV. Python makes everything medium difficulty which can be a big win depending on the size of automation required.

kortex 5y ago

I myself kind of went full circle. I started mostly python, then started to really embrace bash, mainly because I joined a company where everyone else used it a ton, got pretty decent at it. Even wrote basically a primitive container orchestrator in Bash because my PM didn't want to use anything "newfangled". Then I joined a startup at basically the ground floor, and it's almost entirely pure python, with some Makefiles to automate common operations. All that to say, I have a lot of experience with both paradigms. And frankly...bash kinda sucks as a programming language and environment. It's a footgun factory. Even when I was most fluent, I constantly had to deal with nested quotes, escaping, stringly types, empty variables, implicit behavior. Python's biggest weak point is definitely its packaging and dependency ecosystem... but it at least has one. Bash doesn't even have modules. And it's gotten MUCH better over the years, with pyproject.toml, poetry, actual version resolvers, pipx makes managing venvs for cli tools way easier. "but bash is everywhere" says many folks. yeah, and? There was a point in time where it wasn't. Python is seeing way more market penetration. Xonsh (python based shell) and plumbum (python library which makes pipe-operating and subprocessing easier) are both great.

chihuahua 5y ago

I once worked for a company that had a product which had a fairly complicated and time-consuming build process. Someone had written a distributed build process using the traditional CMD.exe shell scripting language. It was running multiple processes in parallel, and they communicated by writing and reading text files. Later they added PowerShell scripts. All in all, there were tens of thousands of lines of PS and BAT scripts. It was quite a nightmare. The team was supposed to maintain this mess. We decided to create a compiler that translated .BAT scripts to C#. The idea was that the C# code would be easier to understand and modify. I left before it was complete, so I'm not sure how that worked out. But last I heard, they were pleased that some parts of it now ran thousands of times faster.

noasaservice 5y ago

Im dealing with some python3 crap today on my main laptop. Primarily, because of a library I compiled and installed, I'm getting other nasty side effects form it. Primarily that protonvpn-cli isnt now running becasue of some broken library. I've never had bash break like that. Quirks, sure. But never this sort of brokenness.

kafkaIncarnate 5y ago
I had a similar problem with the YouTube plugin for Kodi recently. Turned out to be some weird Python 3.10 regression that took over a month to fix. For ProtonVPN you can also use the OpenVPN config files they provide to avoid any Python client issues. Ironically I have a Bash script written around that to generate individual ovpn files as needed from the zip for myself.

sigmonsays 5y ago

having a hard time being sold here. mkdir -p would create the directory without error. checking if a directory exists is trivial before creating it. Python throws an error if the path given to os.mkdir exists too. This article is way too long to digest, so i should stop now. Perhaps the argument should be, rewrite hacky things in bash as programs and build them into your apps?

rstuart4133 5y ago
I've written a lot of bash scripts in my time, even some 10,000 liners. Christ - I have probably written over 100k lines of them. The big ones (by big I mean say over 100 lines) all started life when I thought they would remain under 100 lines. I'm a professional programmer by trade. Admitting to starting a program I know would be over 100 lines in shell script would be close to an admission of incompetence, because technically shell script is one of the worst computer languages out there. So I'd never admit to it. But it's so damned portable, and ubiquitous and the batteries it comes with (the 'nix cli tools) are to powerful and complete, it makes irresistible at times. Where this article falls down is they are recommending Python3. Python2 would be fine. But in 'nix environments, where file names and configuration files can't be treated as text (Unicode) because there is no well defined system encoding, Python3 manages to introduce more rare bugs than shell script. It encourages you to treat everything a text, the dies ignominiously when decoding the 'nix byte stream (file name or whatever) fails. (On Windows where everything is UTF16, this isn't a problem - for local files. It remains a problem for data from external systems, like the internet.) Pull off making a programming language less reliable than shell was a mean achievement - but the Python3 devs did it. Hats off to 'em.
rawoke083600 5y ago
>This article is way too long to digest, so i should stop now. Lol one of the top problems with having "scripts" in python, their reliability-lifetime" (a.k.a as execute-and-forget) is very limited. Packages are outdated, api changes etc etc

readingnews 5y ago

I have some bad news for you, from a long, long, long time CS/EE/Sysadmin person: I can probably run my bash script on every linux I ever touched. I can probably have that python code break on half of the linux boxen I use. This one does not have module X installed. This one is too old, this one is too new, this python is not holding its mouth just at the right angle to work. Yeah, bash bash all you want. I have pulled out scripts decades old and run them. I can not say the same for other things I have written.

drewcoo 5y ago
But which one is more likely to also run on Windows? /s
- yjftsjthsd-h 5y ago
  ... Hilariously, I think shell might actually win that; neither is installed by default, but you get some sort of bash/sh with any of interix, WSL1/2, git, cygwin, or mingw.
  - DyslexicAtheist 5y ago
    isn't WSL like a hypervisor that runs a guest? I'm clueless about Windows but when I start a WSL it is usually some form of Debian or Ubuntu that I can download from the Microsoft "store". Therefore isn't the shell you have whatever comes with that guest?
rawoke083600 5y ago
>I can probably run my bash script on every linux I ever touched. Exactly THIS !
- DyslexicAtheist 5y ago
  yeah python (and before perl with cpan) had these issues that maintaining a consistent system is more effort than writing the damn thing in the first place. I loved Perl but tried to avoid modules like the plague. And python is almost worse because the same mentality (avoid modules) was abandoned by most of the community so now you get incompatibilities with what the OS provides and what gets installed via pip. Perhaps it's unfair to pick at python for this when many of these issues are not the language but because people picking python when they should have just used shell script.

jrm4 5y ago

This feels like: "Moving furniture by throwing it in the back of a pickup truck is obviously bad. Here's how to do it with a forklift and 18-wheeler instead, because this is definitely better."

vonseel 5y ago

Places that I've implemented shell/utility scripts in Python tend to do so because their other application code was also in Python and Python has much more testing support than bash scripts will ever have. That's why I've done it before, to write tools like custom log rotating / clean-up stuff; another project that comes to mind was a data pipeline that used some Python regex stuff to clean up non-printable characters and ugly stuff from text files before importing data. Both of these projects had lots of tests to verify that the code did what we wanted it to do.

drewcoo 5y ago

I think some of the examples of Python being better are places you just shouldn't use Bash. Like testing (Bats sucks). Like string manipulation (use other utils or even languages callable from Bash). Like complicated logic. Just don't do that in Bash. Bash is for (glorified) one-liners. And for I-can't-believe-you-did-that-in-Bash-ers.

emacs28 5y ago

I decided a while ago to write all my future scripts in Python whenever possible instead of sh or bash due to the overall better syntax and power of Python. Typer is one of the better packages for running Python scripts from CLI. Fabric & Invoke are pretty good too. To run any bash commands in Python I have a Python script that creates a temporary bash file with the code to execute, makes it executable, runs it with the commands in the built-in subprocess package, then deletes the file. This makes any complex bash commands with piping and whatnot runnable straight from Python. This way I don't have to learn all the different bash-based Python commands from pathlib and whatnot that throw unexpected errors, and I can run them using pure bash syntax from Python. But then you also get all the benefits of Python's looping syntax, classes etc.

lawwantsin17 5y ago

adityaathalye 5y ago

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 )

ComradePhil 5y ago

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-language-that-looks-the-same-before?utf8=%E2%9C%93&id= https://www.goodreads.com/quotes/tag/437174-perl-the-only-la...

ms4720 5y ago

TCL would be a better choice, more so back then.

deleted 5y ago

[deleted]

Brian_K_White 5y ago

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.

kafkaIncarnate 5y ago
That's what Python2.7 is and why every major proprietary product won't adopt anything else. It's also why it won't go away. All of my Python 2.6-2.7 scripts haven't been touched in 10 years in production and they aren't likely to ever be updated. I actually now refuse to write new Python that isn't compatible with both 2&3 for this reason. Python3 refuses to stabilize.
- fiddlerwoaroof 5y ago
  I’ve been slowly embracing the mantra “only use unmaintained software”: maintenance is great when it’s fixing bugs and such, but eventually people insist on breaking backwards compatibility.
  - Brian_K_White 5y ago
    That is a captivating idea!
  - kafkaIncarnate 5y ago
    Python2.7 is still maintained. If you mean my software I mentioned if something breaks I'm still required to fix it. I just doubt that will happen at this point and have other tasks to do.

gorgoiler 5y ago

The one thing about Python that makes it so much more compelling over Bash is that thing you discover you need once your script starts getting long and repetitive: functions, with arguments, and return values. Python does this much better than Bash. It’s the one thing that makes me no longer use Bash. Oh and exceptions. Exceptions! The TWO things about Python that make it more compelling are functions and exceptions. You stand a chance of handling errors in Python. In bash there’s very little else you can do, when encountering an exceptional situation that is an error, except stop. The nice thing about all these functions is you can put them in modules as well. Modules! Of course! A namespaced way of laying out non trivial amounts of code! Ok so real functions, exceptions, modules. Three things that makes Python my default tool of choice. And libraries. Bash doesn’t have pip. Sure, bash’s “pip” is the commands it can run aka /usr/bin, but if that’s your interface then it’s hardly as flexible as say gitlab.py or requests.py. So: apart from the functions, exceptions, modules, libraries. And speed. SPEED! And code formatting. And a debugger. And stack traces. …what has Python ever given us that makes it a no brainer replacement for bash scripts? “Brought Unicode” ”Unicode! Oh shut up!” — After MP

cuteboy19 5y ago
Typically you don't want to do dependency management for simple scripts, but that's fine because python is batteries included
DyslexicAtheist 5y ago
> And speed. SPEED! Maybe I'm just a terrible python programmer and also all those around me suck at it but in 20+ years I have yet to see a well optimized python script faster than a well optimized bash/ash/csh/ksh/zsh script. Maybe your point is true if a script constantly does foo=`some thing` and constantly shells out other commands.
- gorgoiler 5y ago
  I was thinking of the time I calculated IPV6 EUI64 suffixes in bash for a kind of janky IPAM thing, and how even the barest minimum of arithmetic turned “instantaneous” into “takes seconds”. The bash-centric solution was to write a little eui64.c and call that from the script. Bash isn’t for doing things, it’s for making other programs do things. That worked fine for a bit, but in the end it just became easier to factor and reason about the project when it wasn’t a weird mixture of clever things, and one Pythonic lump of boring and predictable things.

rawoke083600 5y ago

Yo - I'm sure there are advantages, but "that python ecosystem" ! Bash is usually everywhere even on "new installations". I'd hate to fight package compatibility, virtual environments etc.. YMMV

liendolucas 5y ago

I didn't even read the article. The reason is that it depends what you need to do, from there you should decide what's the best tool to solve something. Recently I've started to automate all the package installations and configurations for some of the machines I have. I can't even imagine doing that in Python despite I've been using Python for a long time. I don't know that much about bash, but I got everything I needed and expected from bash scripts for the task I needed to do. Yes, there are moments when you try to solve something in bash that you think is trivial in other languages but with bash is painful. Few days ago tried to test if a value is present in a bash array using a function. Couldn't get it working after trying few things. Then I realized I could perform a very similar (and good enough) check just seeing if a directory and a file do exist in my relative path to the script I was running: `if [-d DIR ] && [ -f FILE ]; then ...`. So I needed to change my mindset a bit. Another example of where bash is really good is for tiny small tasks: I wrote a small script to increase/decrease volume that is coupled in i3 and calls the `mixer` command in FreeBSD. Works perfectly and never touched once it was working. Another one: I get an acoustic alert when my battery drops down below certain percentage. And a couple more: set a random background every time I log in to i3, download a page for offline reading. Again, doing any of these things (or similar ones) with something different than bash (or maybe your favorite shell lang) seems like picking up the wrong tool for the job. There was a time when I cursed shell scripting a lot and that was because I couldn't see when to use shell scripting. EDIT: Paragraph spacing.

rawoke083600 5y ago

I guess, if you really want a "coding-lang" rather than "just" bash. I'd give Golang a try, just because of the static-binaries. No environment issues or missing and clashing libraries. PS. I'd still go for bash 99/100.

vermaden 5y ago

Showing the code as images instead of text and not even with a fixed width font for code ... and I am suppose to trust that person? :)

MichaelMoser123 5y ago

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. https://github.com/MoserMichael/subb https://github.com/MoserMichael/subb https://pypi.org/project/subb/ https://pypi.org/project/subb/ Python doesn't have the problem of shell scripting language, it doesn't get impractical, as the program is getting more complex. In bash you have arrays, and even maps, but these aren't pretty. Also the shell scripting language is being evaluated by an parse tree/AST interpreter, that's significantly slower than even python, in it's byte code interpreted form. 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 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.

deleted 5y ago
[deleted]

mannykannot 5y ago

I agree with the general thesis that Bash is unsuited for production work of any complexity, but the coverage of pipelines is incomplete. The only two examples I have found (the examples are images, so I may have missed something) may be implemented in Python by calling sorted(), which is not the case in general. I feel it would be more persuasive if it had at least one example of setting up and running a pipeline.

sqqqqrly 5y ago

I love to write Makefile recipes that wrap bash into small make commands. My make boilerplate generates help from comments in the make file. I get completions for free. I want all make vars and some internal make recipes to not complete, so I prepend the name with an underscore. Make is great because it handles errors and dependency trees.

hulitu 5y ago

> Without much real work, it’s easy to replace shell scripts with Python code. The revised code is easier to read and maintain, runs a little faster, and can have a proper unit test suite. And give a wonderful syntax error.

conquistadog 5y ago

I've spent many years becoming quite fluent in bash. It's not trivial. But all objections here are surmountable if not outright features. Python is the right tool for many jobs. But so is bash, for someone willing to truly learn it.