So I’ve been using Linux now for a while, and am looking to migrate my dev environment to vim and spend more time in the command line. I’m fairly comfortable with bash but by no means an expert. I’ve used zsh with some minor customization but just recently learned about fish. I’d love to hear people’s opinions.
I use a mix of fish and nu depending on what I’m doing. NuShell is great but still pretty buggy, so I use fish as my default and switch to it when I want to use its features.
I still write most of my stuff in bash however since servers I work with typically only have bash, and so are potential coworkers.
But locally I see no point restricting myself to a POSIX compatible shell, especially for interactive shells. The easier and faster it is to use and customize the better. Being able to parse and use JSON and CSV and other things easily and natively right in the shell is a major quality of life improvement!
Why not use Perl or python for scripting tasks? Bash script is terrible imo.
I mean, I guess technically Perl could do but it wont earn you any favors from your coworkers.
I do use Python for higher level stuff but I don’t see a point to go Python when you’re just gonna call 20 subprocess anyway to do like apt update apt dist-upgrade apt install wget this untar this rsync this. Especially when you can’t even assume you’re going to have Python to provision the box.
That’s why I included Perl, it is always there. Just don’t code as if you were in the nineties and Perl is a perfectly legitimate language, even more so for shell tasks. Bad and good doesn’t depend so much on the language but the coder.
IMO there’s also a component where a good coder will pick the best suited language for the task, but will also pick something that the rest of their (potentially less skilled, junior or even intern) team won’t be scared away by.
If you’re mostly just running a few commands and writing to a bunch of files, bash is great and does that in almost no code and remains quite readable. Like, a backup script for a database is essentially a bash one-liner. I’m sure it’s also easy in a Perl script, but just seeing a .pl file can scare some admins whereas they know what to expect if they see a .sh.
Then there’s also a component of, what does the company uses. If the company runs Ruby apps, then I’d write tooling in Ruby. If the company runs PHP apps, some of the tooling will be written in PHP.
It’s very circumstantial in the end. I’ll definitely whip up some Perl if it’s advantageous, but really most of the time it’s just wrapping an rsync or whatever, and at work it’s usually just some glue or bootstrapping something like Puppet or Ansible. Not a fan of those personally but it’s a safe bet for my role and industry.
On the personal side, I tend to turn to what’s my favorite language at the moment, so lately I’ve been practicing my Rust.