> Bash is the tool that’s already there; that is always a real good reason to use it.
If you are a dotnet dev shop, it is quite likely that dotnet is also a tool that is already there the places you need automation.
Plus, its also the tool that is already there in your team’s skillset.
I am an old hat. I've been in dotnet dev land for decades and still use bash (git bash).
Pros:
Syntax + access to familiar shell commands
Cons:
Bash scripts are not easy to maintain.
Not an old hat. in the dotnet world for 3 years, bash over a decade. Agree with bash not being easy to maintain.
Argument about bash being always there breaks down quickly. Even if you limit yourself to bash+awk+grep, they dont work consistently across different bash flavors or across platforms (mac/win/linuz).
My approach now is to have my programs, in the language most convenient to me, compiled to a bunch of archs and have that run across systems. One time pain, reduces over time.
> Argument about bash being always there breaks down quickly. Even if you limit yourself to bash+awk+grep, they dont work consistently across different bash flavors or across platforms
IMO this is why Perl was invented and you should just use Perl. Bash isn't portable and isn't very safe either. If you're only going to use a couple of commands, there's really no reason to use bash. The usecase, in my head, for bash is using a variety of unix utils. But then those utils aren't portable. Perl is really great here because it's available on pretty much every computer on Earth and is consistent.
Except Windows, of course. You can install it there but it's plainly obvious it's in a foreign environment.
A lot of people focus on Perl's bad reputation as one of the first web languages instead of its actual purpose, a better sh/awk/sed. If you're writing shell scripts Perl's a godsend for anything complex.
I worked at a dotnet shop a few years ago back. We still used bash over powershell unless we required COM
There's still version/dependency hell (one thing wants 6, one thing wants 8, one thing wants 8.1, etc.).
This can be managed but you have to manage it.
(A fanatical commitment to backwards compatibility can make this a lot easier, but it doesn't seem to me that dotnet has that.)