6 ms·

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. Als

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.

lsaferite 1y ago
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.
- forrestthewoods 1y ago
  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.
  - zahlman 1y ago
    And now you also understand many of the limitations LLMs have.
osigurdson 1y ago
Nobody likes coding in bash but everyone does it (a little) because it is everywhere.
- forrestthewoods 1y ago
  > because it is everywhere Except for the fact that actually it is not everywhere.
  - nativeit 1y ago
    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.
    - forrestthewoods 1y ago
      > 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.
      - osigurdson 1y ago
        If you use git on Windows, bash is normally available. Agree, that this isn't widely used though.
        forrestthewoods 1y ago
        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.
        osigurdson 1y ago
        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.
hollerith 1y ago
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!
- nativeit 1y ago
  > 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?
  - hollerith 1y ago
    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.
    - nativeit 1y ago
      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).
zahlman 1y ago
> 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/ 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.
- forrestthewoods 1y ago
  Ok?

lsaferite 1y ago

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.

forrestthewoods 1y ago
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.
- zahlman 1y ago
  And now you also understand many of the limitations LLMs have.

osigurdson 1y ago

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

forrestthewoods 1y ago
> because it is everywhere Except for the fact that actually it is not everywhere.
- nativeit 1y ago
  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.
  - forrestthewoods 1y ago
    > 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.
    - osigurdson 1y ago
      If you use git on Windows, bash is normally available. Agree, that this isn't widely used though.
      - forrestthewoods 1y ago
        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.
        osigurdson 1y ago
        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.

hollerith 1y ago

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!

nativeit 1y ago
> 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?
- hollerith 1y ago
  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.
  - nativeit 1y ago
    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).

zahlman 1y ago

> 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/ 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.

forrestthewoods 1y ago
Ok?