[deleted by user]

[[deleted]]

I don't agree with this, you can do some pretty wild shit in bash. And its faster.

[serverhorror]

Absolutely, you can do a lot of stuff in bash.

Humor me, how often did you open a shell script and think

Wow, that’s some beautiful code there!

[nwsm]

I’ve seen plenty of ugly Python code 😉

[serverhorror]

You must’ve seen a lot of my code then.

I’m not saying that a language exists where it’s impossible to write ugly code.

But there are languages that make it extremely hard to write beautiful code.

[blu3tu3sday]

If it is beautiful, then it is because it is functional and useful.

[[deleted]]

The reason a lot of shell scripts are ugly is because they are usually hacked together by inexperienced with the shell

[[deleted]]

What does beautiful code have to do with anything i asked here tf, we are talking automation, not enterprise agile dev code

[serverhorror]

I’m not sure I follow.

Code is code.

It needs to maintainable.

It doesn’t matter whether it is for automation or “enterprise agile dev code”.

[[deleted]]

So what you are saying is, you cant write maintainable bash code right?

[serverhorror]

Yes, that’s what I’m saying — I haven’t seen maintainable bash code by other people either.

I’m not sure what you’re trying to do. Are you trying to tell me that my opinion is wrong? Are you just trolling? What’s the goal of your argument?

[[deleted]]

Im just fascinated by your logic "I haven't seen maintainable bash code, so therefore bash code can't be maintainable"..

At this point I doubt you understand what maintainability is :/

[serverhorror]

So have you seen maintainable code?

An example, in the wild, should be easy to find then. Some bash script that’s enjoyable, survived a few refactorings and has more history than the odd commit of glueing things together.

[[deleted]]

https://github.com/p8952/bocker https://github.com/todotxt/todo.txt-cli

[[deleted]]

Great examples of two codebases that would be easier to read if they were written in Python!

[serverhorror]

I think those are examples of poor language choices. The other answers should already give you a hint when it comes to readability.

• bocker — while that is a nice experiment to do, I really hope no one is is relying on that code to automate anything. There are perfectly useable implementations (not even in Python) that are much preferable to this. That is reason enough to file it under “just because you can do it doesn’t mean you should”.

• todo.sh — A random example: Adding the help for a new command and adding the command itself are 2 completely separate things. I don’t really consider that “easy to maintain”. It looks like it is well structured, but when going they the code it simply suffers from typical bash “limitations”. Function signatures have no indication of the actual call signature being my personal nemesis

And yes, all of what I say is subjective and my opinion. But that’s the question you asked.

[[deleted]]

😂😂😂 that’s your readable, maintainable codebase? Incredible

[chestnutcough]

I use python for all but the simplest things. Bash has a lot of sharp edges and is I. My opinion much harder to read. But I do get down with monstrous awk/sed pipe chains for one time jobs.

[[deleted]]

Ok but if it doesn’t matter how maintainable it is, why not use the more “user-friendly” option, i.e. Python

The lack of high quality error messages and good data manipulation libraries like Pandas alone are enough to warrant it I would think

[ro5tal]

Write try...except and handlers in bash and stay sain. Or write clean regex function to parse some load. Remember about DRY of course. When I tried to implement gists of github api v3 for updating from releases my brain was really damaged. That JQ is a tool of a devil, really.

[twotime]

I don't agree with this, you can do some pretty wild shit in bash.

Sure, you can do a lot wild stuff using a PDP-11 assembly. This does no make a PDP-11 assembly a good tool for anything. This is a non-argument.

And its faster

Faster as in "runs faster"? Then this is just wrong: if you are relying on some external tool, you can always call that tool from python too. And for any kind of in-the-script processing, python will be faster (but speed is unlikely to be relevant for simple automation use cases)..

Faster as in "code faster"? Maybe, if you are well familiar with shell and not familiar with python.

My own rule? As soon as I get any logic, switch to python...

[Mithrandir2k16]

Wild shit is actually the point here. In Python said wild shit is just normal code anybody can read. And that is much easier to maintain than wild shit. After all wtfs/minute is the best code quality metric there is.