> "I don't know and I don't want to learn" instead of blaming a language.

I'm a staunch proponent of "anything over 100 lines should not be written in bash". You can do many more things easier and with less google-fu to find your niche SO answer.

Unless you have absolutely no clue about other scripting languages that already exist on Debian, just don't do it, there's so many better options that actually last and can even be read by other people.

I used to say the same thing, back when the only bash I knew was from whatever tidbits I picked up as I needed them. Then I got more familiar with bash. Now, nearly everything I write is bash. I have realized that more complex languages mostly just make things.... more complex, rather than simplifying them. For simple solutions I stick to simple tools, even if it takes more than 100 lines.

Here's one tool I wrote in Bash. It's an alternative to Terragrunt. 616 lines. https://github.com/pwillis-els/terraformsh

Here's another one. A static-app package manager/versioner/pinner thing. 409 lines of POSIX shell (the code is intentionally ugly, don't take this as an example of good code). https://github.com/peterwwillis/clinst/blob/main/clinst

For both of these tools, 90% of what they do is just managing environment variables and calling other programs, and that's what shell scripts are best at.

Sure, sorry if I was too harsh on bash here :) It really wasn't the right tool for the job in some parts of my use case though – parsing info out of Sources.gz using awk and sed and friends is just plain bad compared to using python-debian to get the info directly from the apt database.

I read it as somebody who knows they're sufficiently bad at bash to not be safe with it admitting that and doing something more sensible for their specific context.

NB: When I say "sufficiently bad at bash" I think of myself first. Just because I know about 'set -e' and friends doesn't mean I trust myself to get it right nor do I believe anybody else should trust me to either.

But Python works great when called from shell! I learned Python first, then shell, so my shell scripts largely use Python instead of sed/awk (except for the most basic cases).

This includes both inline invocations like python -c, but more commonly simply a .py file in the same directory as the shell script.

So I think of shell as the main(), and then it often calls Python and R. (One big reason I started using shell was for preparing data in Python and then analyzing it in R.)

That said, I think shell needs better support for JSON and TSV so you can interoperate with languages like Python, JS, and R better. Things like the 'read' builtin aren't great for this.

Thanks for taking my criticism as constructive! (that's how I meant it.) I found myself very interested in the exploration and discoveries that guided your process.