Tools: Code Is All You Need

Unpopular Opinion: I hate Bash. Hate it. And hate the ecosystem of Unix CLIs that are from the 80s and have the most obtuse, inscrutable APIs ever designed. Also this ecosystem doesn’t work on Windows — which, as a game dev, is my primary environment. And no, WSL does not count.

I don’t think the world needs yet another shell scripting language. They’re all pretty mediocre at best. But maybe this is an opportunity to do something interesting.

Python environment is a clusterfuck. Which UV is rapidly bringing into something somewhat sane. Python isn’t the ultimate language. But I’d definitely be more interested in “replace yourself with a UV Python script” over “replace yourself with a shell script”. Would be nice to see use this as an opportunity to do better than Bash.

I realize this is unpopular. But unpopular doesn’t mean wrong.

Python CAN be a "shell script" in this case though...

Tool composition over stdio will get you very very far. That's what an interface "from the 80s" does for you 45 years later. That same stdio composability is easily pipe into/through any number of cli tools written in any number of languages, compiled and interpreted.

Nobody likes coding in bash but everyone does it (a little) because it is everywhere.

Me, too. Also, Unix as a whole is overrated. One reason it won was an agreement mediated by a Federal judge presiding over an anti-trust trial that AT&T would not enter the computer market while IBM would not enter the telecommunications market, so Unix was distributed at zero cost rather than sold.

Want to get me talking reverentially about the pioneers of our industry? Talk to me about Doug Engelbart, Xerox PARC and the Macintosh team at Apple. There was some brilliant work!

> because it is everywhere

Except for the fact that actually it is not everywhere.

Composing via stdio is so bloody terrible. Layers and layers of bullshit string parsing and encoding and decoding. Soooo many bugs. And utterly undebuggable. A truly miserable experience.

I see your point, but bear with me here--it kind of is.

I suppose if one wanted to be pedantically literal, then you are indeed correct. In every other meaningful consideration, the parent comment is. Maybe not Bash specifically, but #!/bin/sh is broadly available on nearly every connected device on the planet, in some capacity. From the perspective of how we could automate nearly anything, you'd be hard-pressed to find something more universal than a shell script.

> Also, Unix as a whole is overrated. One reason it won was an agreement mediated by a Federal judge presiding over an anti-trust trial that AT&T would not enter the computer market while IBM would not enter the telecommunications market, so Unix was distributed at zero cost rather than sold.

What did Unix win?

> you'd be hard-pressed to find something more universal than a shell script.

99.9% of my 20-year career has been spent on Windows. So bash scripts are entirely worthless and dead to me.

Mind share of the basic design. Unix's design decisions are important parts of MacOS and Linux.

Multics would be an example of a more innovative OS than Unix, but its influence on the OSes we use today has been a lot less.

If you use git on Windows, bash is normally available. Agree, that this isn't widely used though.

Yeah I’ve never see anyone rely on users to use GitBash to run shell scripts.

Amusingly although I certainly use GitHub for hobby projects I’ve never actually used it for work. And have never come across a Windows project that mandated its use. Well, maybe one or two over the years.

I suppose the deeper question I'd have would be, how would its no-cost distribution prevent better alternatives from being developed/promoted/adopted along the way? I guess I don't follow your line of logic. To be fair, I'm not experienced enough with either OS development nor any notable alternatives to Unix to agree/disagree with your conclusions. My intuition wants to disagree, only because I like Linux, and even sort of like Bash scripts--but I have nothing but my own subjective preferences to base that position on, and I'm actually quite open to being better-informed into submission. ;-)

I'm a pretty old hat with Debian at this point, so I've got plenty of opinions for its contemporary implementations, but I always sort of assumed most of the fundamental architectural/systems choices had more or less been settled as the "best choices" via the usual natural selection, along with the OSS community's abiding love for reasoned debate. I can generally understand the issues folks have with some of these defaults, but my favorite aspect of OS's like Debian are that they generally defer to the sysadmin's desires for all things where we're likely to have strong opinions. It's "default position" of providing no default positions. Certainly now that there are containers and orchestration like Nix, the layer that is Unix is even less visible, and infrastructure-as-code mean a lot of developers can just kind of forget about the OS layer altogether, at least beyond the OS('s) they choose for their own daily driver(s).

Getting this back to the OG point--I can understand why people don't like the Bash scripting language. But it seems trivial these days to get to a point where one could use Python, Lua, Forth, et al to automate and control any system running a nix/BSD OS, and nix OS's do several key things rather well (in my opinion), such as service bootstrapping, lifecycle management, networking/comms, and maintaining a small footprint.

For whatever it's worth, one could start with nothing but a Debian ISO and some preseed files, and get to a point where they could orchestrate/launch anything they could imagine using their own language/application of choice, without ever touching having touched a shell prompt or writing a line of Bash. Not for nothing, that's almost certainly how many Linux-based customized distributions (and even full-blown custom/bespoke OS's) are created, but it doesn't have to be so complicated if one just wants to get to where Python scripts are able to run (for example).

What do you suppose the proportion is of computers actively running Windows in the world right now, versus those running some kind of *nix/BSD-based OS? This includes everything a person or machine could reasonably interface with, and that's Turing complete (in other words, a traffic light is limited to its own fixed logic, so it doesn't count; but most contemporary wifi routers contain general-purpose memory and processors, many even run some kind of *nix kernel, so they very much do count).

That's my case for Bash being more or less everywhere, but I think this debate is entirely semantic. Literally just talking about different things.

EDIT: escaped *

I think if someone were, for example, to release an open source C++ library and it only compiles for Linux or only comes with Bash scripts then I would not consider that library to be crossplatform nor would I consider it to run everywhere.

I don’t think it’s “just semantics”. I think it’s a meaningful distinction.

Game dev is a perhaps a small niche of computer programming. I mean these days the majority of programming is webdev JavaScript, blech. But game dev is also overwhelmingly Windows based. So I dispute any claim that Unix is “everywhere”. And I’m regularly annoyed by people who falsely pretend it is.

Most OSes no longer have any users or squeak by with less than 1000 users on their best day ever: Plan 9, OS/2, Beos, AmigaOS, Symbian, PalmOS, the OS for the Apple II, CP/M, VMS, TOPS-10, Multics, Compatible Time-Sharing System, Burroughs Master Control Program, Univac's Exec 8, Dartmouth Time-Sharing System, etc.

Some of the events that help Unix survive longer than most are the decision of DARPA (in 1979 or the early 1980s IIRC) to fund the addition of a TCP/IP networking stack to Unix and the decision in 1983 of Richard Stallman to copy the Unix design for his GNU project. The reason DARPA and Stallman settled on Unix was that they knew about it and were somewhat familiar with it because it was given away for free (mostly to universities and research labs). Success tends to beget success in "spaces" with strong "network externalities" such as the OS space.

>Getting this back to the OG point

I agree that it is easy to avoid writing shell scripts. The problem is that other people write them, e.g., as the recommended way to install some package I want. The recommended way to install a Rust toolchain for example is to run a shell script (rustup). I trust the Rust maintainers not to intentionally put an attack in the script, but I don't trust them not to have inadvertently included a vulnerability in the script that some third party might be able to exploit (particularly since it is quite difficult to write an attack-resistant shell script).

OK, consider the browser market: are there any browsers that cost money? If so, I've not heard of it. From the beginning, Netscape Corporation, Microsoft, Opera and Apple gave away their browsers for free. That is because by the early 1990s it was well understood (at least by Silicon Valley execs) that what is important is grabbing mind share, and charging any amount of money would severely curtain the ability to do that.

In the 1970s when Unix started being distributed outside of Bell Labs, tech company execs did not yet understand that. The owners of Unix adopted a superior strategy to ensure survival of Unix by accident (namely, by being sued -- IIRC in the 1950s -- by the US Justice Department on anti-trust grounds).

> Python environment is a clusterfuck. Which UV is rapidly bringing into something somewhat sane.

Uv is able to do what it does mainly because of a) being a greenfield project b) in an environment of new standards that the community has been working on since the first days that people complained about said clusterfuck.

But that's assuming you actually need to set up an environment. People really underestimate what can be done easily with just the standard library. And when they do grab the most popular dependencies, they end up exercising a tiny fraction of that code.

> But I’d definitely be more interested in “replace yourself with a UV Python script” over “replace yourself with a shell script”.

There is no such thing as "a UV Python script". Uv doesn't create a new language. It doesn't even have a monopoly on what I guess you're referring to, i.e. the system it uses for specifying dependencies inline in a script. That comes from an ecosystem-wide standard, https://peps.python.org/pep-0723/. Pipx also implements creating environments for such code and running it, as do Hatch and PDM; and other tools offer appropriate support - e.g. editors may be able to syntax-highlight the declaration etc.

Regardless, what you describe is not at all opposed to what the author has in mind here. The term "shell script" is often used quite loosely.

And now you also understand many of the limitations LLMs have.

Ok?

Unix is everywhere. Except for Windows Desktops and a few places that like to run Windows Server enviroments. Those are increasingly rare.

So Unix is everywhere. Except for the places it’s not.

And “increasingly rare” does not mean “rare”. And even if it were “quite rare”, which it isn’t, that doesn’t imply “not supported”.

And just to add salt to the wound Linux is a profoundly worse dev environment. It’s quite the tragedy.

Lot's of Microsoft shops (majority even) use ADO which is basically github + project management. I'd say most devs targeting Windows use git in some form. If not, what are you using? If git is installed, so is git bash. So bash is basically everywhere, even on Windows. The difference is, I'd say 1/50 devs using Windows actually know this.

The video games industry uses Perforce. I currently use what is publicly referred to as Sapling.

Even if GitBash is installed, and I’m happy to concede it is, there are a variety of hurdles. Both technical and practical. But I will concede it is technically possible.

I will however maintain that bash is not everywhere in practice. And that if you write libraries or projects that expect Windows users to run bash scripts then you’re a bad software engineer and a bad person. Don’t do that.

Integrating something that required running under GitBash would be a non-starter at my current company. That’s just not how literally anything works. So sure technically possible. But with enough effort anything is possible!

Well, at least you know that you can use bash on Windows now. Maybe they will integrate in directly as an alternative to cmd and powershell one day. That would be nice.

My first software internship in college, I was at a Microsoft shop. I ended up astonishing the people I worked with (who were all programmers) by automating solutions to some annoyances I ran into, some menial tasks I was assigned to do, etc. I did it all with Cygwin or MSYS, although I don't remember whether the scripts were Bash or Fish.

All of my co-workers could have written their own code to automate such tasks. They even had access to PowerShell, which was by then part of Windows.

But they didn't, because they didn't have a shell worth "living in" (PowerShell is much too slow-- and to a lesser extent, too verbose-- for daily interactive use), and writing code to automate the same tasks in a "real programming language" seemed laborious and boring enough that it always made sense to put it off and live with the mess.

Solid bash experience would benefit lots of Windows developers.