When I was a student, I once interned for a company of Windows developers, a Microsoft shop whose work was all in .NET. I remember that there were some tasks I was able to do, having to do with processing many, many little text files, that everyone was surprised I was able to do, or surprised I was able to do quickly. Every time, it was something that I put together in a few minutes with the usual Unix tools thanks to Cygwin.

It's probably true that game development is really different from, say, web development, when it comes to the relevance of Unix. But I think it's also true that often, when you don't know common Unix utils, you don't know what you're missing. I don't think any programmer could master them and regret it.

I don't regret knowing Unix tools. But I very frequently regret that other people chose to write non-trivial operations in a bash script instead of a real programming language! If Unix utils didn't exist and everyone just used Python instead I'd honestly probably prefer that.

What's non-trivial for your purposes, in this context?

Good question. I don't know how to quantify it.

What I do know is that if I encounter the need to debug a bash script I get extremely irritated.

Is it immediately obvious what a script is doing top to bottom? It's probably ok. Does it have a bunch abbreviated and potentially obscure flags? Does it have conditional logic? I'd probably prefer it to be written in Python.

If 100% of bash scripts were written in Python I would not be upset. Although I have similar thoughts on Python! Once gets over a couple hundred lines I'd probably prefer it to be written in Rust!!

I feel all this. :)

Incidentally a lot of my recent work is basically glorified Bash scripts (Nix takes care of portability issues for us, but the language is still Bash), and then we've recently created a tool in Python that we invoke as a command-line application.

I try to write my Bash in a tasteful style: I embrace bash features (since my scripts ship with with a precise version of bash anyway) where they make things clearer or more concise (for instance, associative arrays). I do use bash parameter expansion, mostly to avoid nesting conditionals or long lines that read like

  test ... && declare ...

but I usually include a link to the bash manual page on parameter expansion in a comment next to them as a courtesy. I favor long flags and split most commands with multiple args out across multiple lines.

I do use one bash option via `shopt`, namely `lastpipe`. It lets you assign variables from pipelines, like:

  cat someConfig.toml \
    yj -tj \
    jq -r '.someField.nestedField' \
    read VAR

instead of using a subshell on the right-hand side of an assignment. Almost all of my assignments take that form, and there are no unnecessary intermediate assignments, virtually no mutation of variables, and very few ifs or case statements. I think and hope that it's possible to read any chunk of these scripts, then, with very little context: you can focus on a single pipeline at a time without regard for the rest of the program or any variable assignments.

I also just don't do any parsing or validation of arguments in bash. Once I feel I need those, I use something else. Those scripts aren't things I present to outside teams as interfaces.

I find it easier to read my bash scripts than our Python code, but I don't have much history with Python, and I'm also partial to those kinds of pipelines— they're basically the same as method chaining with `.` to do basic FP stuff in OOP languages like Scala and Java and Ruby.

But I also wonder where the line is and what business my team even has writing Python when none of us has much Python experience at all. We've succumbed to the standard argument that we should use Python because it's easy to hire for, which I think is probably a bad one. As the program gets larger and more complex, does anything come after Python for us? How do we know when it's time or if a given program should (from the start) go there?

I don't know yet, but as I try to level up my Python skills, I'm also starting to learn Rust with writing CLI tools in mind, with the book Command-Line Rust. I'm hoping that after that, the upcoming Refactoring to Rust will help me devise a way to decide when switching to Rust is actually a good vs. bad idea, as well as how to do it.

These days, Windows caught up very well with PowerShell. Actually more UNIX-y than UNIX in some respects.

I love PowerShell, but I've yet to meet someone who 'lives in' PowerShell the way so many 'live in' Bash and the various GNU CLI utilities, which I think inhibits familiarity of the kind most convenient for whipping up quick scripts like that.

That said, PowerShell is much more a 'real programming language' than the shell languages that came before it. PowerShell scripts are a lot more maintainable that scripts written for those other shells. And there are some really powerful things built on top of shell (like DSC, for example) that don't to my knowledge have analogues written directly in other shell languages. Plus PowerShell has an actual package management story, code signing capabilities, and other modern niceties.

But for me and I suspect most others, it falls down as an interactive environment for rwasons of performance and verbosity, and Windows environments themselves are unfortunately still harder to automate or inspect programmatically because most applications don't provide or document PowerShell-friendly interfaces. So I don't think it's surprising that despite all of PowerShell's incredible advancemwnts, you rarely meet Windows users who have invested in it as much as the average longtime Unix user invests in their respective CLI utilities.

But for, say, game developers who say 'Unix is not my environment; I'm not sure I wanna bother with all of that CLI and scripting stuff', they do nowadays have an alternative in that arena which is outstanding in a lot of positive ways. I don't anyone would regret deeply learning PowerShell, either.

Hell, my team at work is all Unix guys. I probably have the most experience PowerShell experience of any of us, which is way less than my GNU command line environment experience. But if someone with deep PowerShell experience joined our team, I'd absolutely encourage them to use PowerShell on Linux wherever we write scripts, and be happy to learn whatever I needed to to keep up. PowerShell is a nice enough language that I think it's very reasonable to bring it with you to other operating systems as well.