You shouldn't have a user account on prod machines. Typically, there's just the user the service runs as. If it's in the cloud, the "machines" are containers. If your company sells on-prem stuff, there's a good chance it's an appliance that's owned by someone else.

If you operate your own data centers, then you need to do configuration management of the machines, so their configurations are immutable/reproducible.

(These problems all arise once you have a large fleet and a large ops team.)

If your fleet is large enough that user accounts are no longer feasible then you probably shouldn't be managing these servers by hand anyway, so the preference of shell becomes irrelevant.

> That's why you can pick your favourite shell for your user account.

nobody cares about user accounts. use whatever you want on your laptop, nobody cares.

however if a script reaches a production server, it should either be sh, bash, or a real programming language (python/ruby/perl/whatever).

the ugly stuff i've seen is that some snowflake user drops their scripts written in ${shell_of_the_week} and leaves, the script breaks and now i have there's this thing that has to be not only fixed, but possibly rewritten from scratch.

I'd caution against python in prod. In addition to supply chain issues with pip ("pip install" in prod is foolish on the best of days), python libraries love breaking compatibility.

The "one off" script from two years ago that you really, really need right now probably won't work. Perl/bash are less likely to hit this (they stopped changing years ago). It's an open question whether golang will have this problem.