> We have vastly better tools now in those niches.

But do we? I'll beg to differ.

Python explodes in to LoC when you try to attempt to work with the OS. You need to source modules that turn the application in to bloat. 98% of def's you don't require.

If you need a multi-purpose tool, or a model than sure. For the simple automation of running a rsync or ZFS snapshot schedule to copy to & from a NAS in a guaranteed timely manner in cron, it works just fine. The overhead of using languages compared to the previous is partly why I keep using bash or Tcl.

    from subprocess import run
    from sys import argv

    source = argv[1]
    destination = argv[2]

    run([
      "rsync",
      "-zavp",
      source,
      destination
    ])

vs

    #!/usr/bin/env bash

    source="$1"
    destination="$2"

    rsync \
      -zavp \
      "$source" \
      "$destination"

the overhead is not really that bad imo

That's not really what people mean. Your example isn't accurate because you just ran bash two different ways.

subprocess.run() uses Popen and defaults shell=False. There is no shell process involved. As the other user already pointed out.

Huh? The Python example does not use Bash or the shell in any way.

For anything more complex than linear shell scripting, I prefer ruby --disable-gems these days. As you say, Python is horrible for composing and executing shell commands, but Ruby's FileUtils#sh (combined with %W{} array literals, %x{} output capturing and regular #{} string interpolation) provides a pretty low-impedance interface.

FileUtils#sh doesn't exist:

    ruby --disable-gems -e 'require "FileUtils"; FileUtils::sh("ls")'

    -e:1:in `<main>': undefined method `sh' for FileUtils:Module (NoMethodError)

> > We have vastly better tools now in those niches.

> But do we? I'll beg to differ.

We do. I mentioned Fish and PowerShell for interactive scripting. Those definitely handle your rsync/zsh snapshot case. If you're OK installing software, xonsh and nushell seem interesting; I briefly played with the latter and it seemed really nice. As usual, bash/zsh/dash win on ubiquity, but ubiquity and quality are utterly disconnected. For heavier languages/Perl-alikes, Lua's not a bad contender here and tends to be widely installed. Ruby, too, is a near-ubiquitous improvement on Bash and Perl, but it emulates the latter more than my personal preference, and is inferior to Python 3 when it comes to uniformity of behavior across versions and included batteries. I think tcl's suboptimal here because it's no longer part of a lot of Linux distros, but it's fine.

Nitty aside: for cron jobs specifically, I find that it's rarely worthwhile to deal with a multi-line shell script: either I can run a single shell-wrapped command directly with output-file redirection, or I go all the way to a language with proper error stacktraces (since about 80% of my simple-cron-job-debugging work tends to be of the "figure out how far it made it before silently crashing" variety). And that's again because of the awful shell default of on-error-resume-next, one of many trash behaviors of bash/sh.

And yeah, the shell is a very easy way to set up cron output capturing; wish it didn't come with all the other warts. If something like "tee" or "xargs" had a single-line invocation form which did everything that "bash -eu[x]c 'rsync <whatever>; echo done' >output.log 2>err.log" does, I'd switch to that in a heartbeat. If you want something outlandish like, I dunno, timestamps on those log lines, well ... enjoy learning about FD substitution or double-escaping awk in a pipe or something (after you shake off the hangover from realizing that you'll have to double-wrap shell invocations because cron only invokes POSIX sh). Yuck.

Hell, so long as I'm saying contentious things that shouldn't be, ideally you'd ditch the cron and use the ubiquitous tool that was explicitly built to work around those exact shortcomings of the shell and cron itself: a systemd timer.

> Python explodes in to LoC when you try to attempt to work with the OS.

Python's ubiquitous and popular, and some extra LoC/uniform copy-paste imports are a trade I and many people gladly make in exchange to not having to worry about rare, niche issues like "what keysmash do I type to get the length of an array" or "what arguments does this function take" or "am I getting the exit code of the last thing that ran, or the intermediate 'grep' I ran on its output". If that trade's distasteful, you can take on a third-party library and get terseness back using something like plumbum. But really, most bash/perl vs python arguments that revolve around line count and verbosity (or whitespace) aren't arguing about whether the tool is capable, they're arguing about aesthetics. Sure, the car's an ugly color, but it drives better.

> You need to source modules that turn the application in to bloat. 98% of def's you don't require.

I don't know what you mean by this. You can "from sys import argv"; you shouldn't "from sys import *". And you're rarely "paying" much to import/compile all the other symbols in the module; most of the modules you'd need for basic shell scripting are either part of the interpreter core or already imported at Python startup anyway. If you don't like even that tiny overhead, well, I have bad news for you about what Perl does when you 'use strict', or what the OS does when Bash makes you launch a subprocess of tail/grep/cat/whatever just to parse a command's output.

Edits: posted the first half early by mistake then added discussion of cron/import cost.

I'll agree to disagree; on this. It's moot at this point. I do however respect your view. Zfs, rSync were just basic examples but where you need to schedule OS commands, zfs snapshots, sync or other system utilities Bash will always be my go to wrapper for it's native-ness to the shell. Maybe my head is more warped for the archaic type of language as I do enjoy Perl however using both Bash and Python is no crime. One orchestrates, one executes.

I don't use Linux and I come from the Unix side of things, FreeBSD is my daily driver, server OS of choice and my father was a Telecoms/unix engineer, maybe that's why. Myself I'm not keen on Python and would personally use something more rough, like ruby if bash was to exit though the door.

I've encountered work systems where backups were performed worked, based on a bash script and everything else on the system was bricked. Nothing would work apart from a shell and a bash script.

I don't disagree, the popularity of Python does make ease. The ecosystem is verse and if someone leaves, someone can pickup where they left up pretty quickly. I just had to shred my (Tcl) PXE server project this week that I created for the VisualFX company gig I'm currently working at.

Now that they are wanting it being Python based, it's soul destroying to get it thrown back in the face when it's been powering company infrastructure for a year only for a LLM to regurgitate what you've worked on for a hard year. It worked flawlessly only for it to produce a Python equivalent in seconds. Python interacting with tFTP, PXE, HTTP , self-generation of Kickstart files, dhcp .. it's a mess and that's what I mean in LoC. 400 lines of Tcl and it works a one click button button.

Maybe I am bias against python because all projects are now within the: "It must be python!" attitude but maybe back in the 80's it was "It must be perl!". I don't know, I only picked up the tail-end of the camel being only 37. Python feels like a constant washed used towel passed from engineer to engineer.

My feel is that a company should be using multiple languages but that costs money. My own project runs on NaviServer, Tcl and Crystal and it glues well but Tcl always was a glue language.

Each to their own, Python isn't for me, it has it's own merits and happy to agree with but I'm not going to praise it to as a shell based language. Python can be a ungodly mess, which I find when you start to incorporate it with relic system services. The debt that LLM's are piling on it isn't healthy.

That's all fair.

I don't think we should abolish sh or anything; it's one of the only truly ubiquitous tools. And folks should know it, the same way they should know nano or ed or whatnot in case they ever get on a system without vim. I just wish it weren't the first resort for so many tasks, you know?

Nitty:

> I've encountered work systems where backups were performed work, based on a bash script and everything else on the system was bricked

I've had better luck with Python in those cases. Even when the shell works, some of the programs my shell scripts call out to are often damaged by whatever broke the system. Python's capabilities are more or less present in memory after "import" and rely on fewer external programs in most cases.

We're similarly aged; I think you might be lucky to have had a lot of fun with tools like Perl early in your career. I got dumped into something of a shell/C/Perl salt mine and had to develop deep expertise in things that I saw more mis-use of than benefit from, so when I discovered alternatives they felt a lot more compelling. Different strokes for different folks I guess. At least we can be thankful that Perl and Python got popular for automation before JavaScript did.

Thanks for the thoughtful replies.