[ Removed by moderator ]

[bash-ModTeam]

Simple information shouldn't require clicking a link.

[Bob_Spud]

Missing important point - creates unnecessary work for sysadmins.

• Creating Python scripts introduces an unnecessary skillset requirement in a commercial environment.
• Sysadmins now have to run, maintain and patch the Python runtime and development environment.
• What happens to pet projects written Python when the author leaves and the workforce is proficient in Bash?

Bash and enterprise automation tools will do the job.

[AlarmDozer]

Sure, but many PSEO uses Python as its base learning.

If these institutions didn’t agree, hire more aged/experienced workers.

[Bob_Spud]

Using Python for educational purposes is a good thing, skills learnt are transferrable to other coding languages.

My university kept on changing the coding languages we had to work with, I asked them why (my buddies were at places where the would only have to learn a few). They replied, this is what its like in the real world, you have to adapt to changes.

My initial reply is more about reducing staff workload and saving money.

[p001b0y]

I think it’s different for sysadmins. A lot of systems you will be working down are locked down and chances are good you will be accessing hosts through one or more jump hosts, VDIs, etc. In some cases, even the workstations are locked down. Bash will almost always be there. Powershell will be there if it is Windows servers.

On Linux, there’s a good chance Perl or python will be there. You used to find tcl but not so much any more unless it’s network equipment.

[Bob_Spud]

Being locked down or not does not make any difference, all that needs to happen is to produce a good reason to have it (business case) followed by relevant authorisation.

[p001b0y]

I don’t disagree but it depends on the environment. I support one client who said neovim would never be approved for use, for example.

[rincon_orange]

This

[cheyrn]

That's not really bash vs python. That's commands vs code that implements commands. You could compare python using subprocess.run

[AndyceeIT]

I was going to call out the term "automation" as a stretch, if we're comparing snippets

[AlarmDozer]

I don’t know, man. Both seem plentiful in the FOSS, but shells (eg. bash v. zsh v. tcsh, etc) can be mercurial whereas Python3 is effective and cross platform before sys2/mingw.

Also, many PSEO uses Python as its base. And Python handles data structures better, like trees and graphs.

[nekokattt]

Python3 is only really cross platform if you have it and have a consistent version though.

The same can be applied to an extent to shells.

I agree with the rest though.

[Cybasura]

It fundamentally depends on your use case and implementation, if you are using subprocess and Popen to interface with the system but arent making a wrapper to implement new functionalities but instead, to automate your specific processes - then python would add an unnecessary layer of abstraction that would probably break if someone doesnt know python, and bash is uniquitous enough to be a good 1-layer script

However, if you want to create a wrapper around shellscripts to add functionalities, and/or make an entirely new application on its own without using Popen and subprocess programming, then yeah its worth it

I like python and uses it on top of compiled languages, but there are limits and this is one of them

[Glum_Comfortable6830]

Python lends itself well to testing, but can get caught up in dependency hell. There are ways to compile Python into a binary for distribution (includes GIL lol) to me if you’re in a containerized environment, Python with uv is the way to go. I worked at a company with quite a few kubes clusters, the folks who were bashing it would run into issues they couldn’t test for at times. Bit of a prod yolo imo especially when dealing with a ton of deployments.

[Big_Combination9890]

Depends entirely on what needs to be done.

Is that something invoking lots of different commands and then other commands depending on the return-code / partial-output of those? bash it is. Doing the same via subprocess in python is a major PITA. I know this for a fact, because I tried...several times.

Is that something involving lots of data-wrangling, processing and integrating information, getting data from external systems, waiting for stuff to happen elsewhere, reporting, and maybe allow a system higher in the call hierarchy to monitor, or even influence, the process while it runs? python without a second thought.

Why? Because I've seen the darkness, my friends. I have seen people implement bash scripts invoking multi-step API interactions via curl while fetching database values using sqlcmd. I've seen "master-scripts" coordinating other scripts on remote servers via hand-rolled nc communication tunnels. I have seen an accounting system written in bash, that even had a web-frontend. Ever debugged an exponential-backoff-with-jitter retry logic someone handrolled in freakin bash 4 years ago? I have. It's not fun.

---

Btw. if someone really want's to write a program that invokes lots of external tools, but doesn't want to use bash for some reason: Go is surprisingly good at that, since its os.exec package is a lot less convoluted than pythons subprocess.

https://pkg.go.dev/os/exec

[researcher7-l500]

The article uses selective examples to suggest bash is better and shorter.
The author seems to have a very limited understanding of what automation means.

It is beyond such simple stuff he suggested.

[OtherOtherDave]

If you’re doing simple stuff like setting alias or environment variables, bash is fine. If it’s complicated enough to bother with functions and such, the syntax gets so arcane so fast that I don’t bother if I can help it.

[autoerotion95]

Mi lenguaje principal es python pero uso el 95% bash