4 ms·

Yes it is. If you have two type systems and you don't want them to interact, gluing them together with stringly typed bash is a good way to keep their scope sm

Yes it is. If you have two type systems and you don't want them to interact, gluing them together with stringly typed bash is a good way to keep their scope small. As a user interacting with multiple programs by different authors, that's a very common use case. Giving your type systems boundaries is a good idea. The alternative tends towards one-type-system-to-rule-them-all, an idea that Russell thoroughly explored in the early 1900's, Godel proved to be unmaintainable in the 30's, and that everybody except the Java and C# crowd has since abandoned as a dead end.

woah 6y ago
It is a pretty sloppy and archaic language. We need an updated version that keeps the string typing and inline execution of external binaries, but has modern syntax, plus a few more conveniences and guardrails.
- __MatrixMan__ 6y ago
  I was only taking issue with the objection to string typing. I totally agree that the rest of bash requires a bit of stockholm syndrome to love. I haven't yet taken the time to play with it but I'm hoping www.oilshell.org addresses some of the warts.
- partdavid 6y ago
  You might be interested in Powershell. I used bash for 20 years and considered myself an experienced user and programmer with it. Comparatively, my experience with Powershell is relatively short, but I switched to it and the first time I needed to handle a piece of structured data I was hooked and haven't looked back.
  - pnako 6y ago
    I recently discovered Powershell, in a Windows context. It's weird, but has interesting ideas, and is better than bash for sure. Supposedly it supports Linux, but I haven't actually tried.
    - partdavid 6y ago
      It does, and MacOS, and I found that once I changed to bash-style tab-completion and used PSReadLine to get the keybindings I was familiar with, it becomes a pretty comfortable shell. I remove some default shell aliases because PowerShell's notion of file modes and permissions ends up not mapping well, but you have all your normal Unix commands available so it's not really a big deal. Quoting is weird but it's not worse than bash, where quoting is also weird. It's surprising how well objects-as-arguments and objects-as-pipelines work, even when mixing with standard Unix commands. I appreciate standard parameter handling, command naming and I think it pays off on the "Unix philosophy" (small program units doing one thing well) better than bash and shell tools. Those standard approaches produce an aesthetic I didn't like for a long time (Invoke-RestMethod -Url ...) but aliases cut down on your typing (irm instead of Invoke-RestMethod) and I now appreciate the discoverability of standard commands. I keep discovering little gems like default parameter values and the various ConvertFrom-* commands, some from modules.
partdavid 6y ago
I don't disagree with your point, in this context. Bash can be good enough for all kinds of things. Or maybe not. But it's not a simple binary equation--there are tradeoffs that might lead you to it or away from it for a particular situation. I do think there are a few issues that make bash non-robust for this kind of task. If you only look at this through the lens of the "type system", you have a good point about gluing views together, but I think "just strings" is not enough typing. I think I and the industry have had better luck with a base system more like JSON, instead of "just strings". It provides enough structure so that there's a straightforward way to turn wire protocols or other external data into your Java objects or whatever, let dynamic scripting languages handle it in their native base types (which often map pretty well to what JSON offers, while bash really doesn't--note that the author here isn') and are fairly reasonable to manage on their own without special tooling. However, that aside, even if "just strings" were fine for everything, the fact that bash is designed as an interactive shell with barewords for strings really exposes a lot of gotchas for handling data from different sources, just from the sometimes-diabolical problems with quoting and I/O. In the absence of actual function return values, capturing output and storing a process exit code, which might sometimes be the last process's exit or maybe something inside the pipeline if you've set the right global options, is error-prone. It's not robust to hope that the only output coming (on two different output streams) constitutes a complete and correctly-anticipated return value from a subprogram. Errors associated with empty variable values are frequent for this reason. Secondly, bash lacks a lot of features which you need external programs to provide, and the dependency management glue between them is not good. You'll need find, ls, sed, awk (and you may not remember the days with multiple significant Unix platforms and differences in behavior between gawk, nawk, awk-of-different-flavors), cut, sort, ps (/usr/bin/ps or /usr/ucb/ps) all stored in different platform- and environment-specific locations and exhibiting different behaviors without a clear way of constraining your dependencies or even asserting them correctly. In the modern world, you can add to that list curl, jq, parallel, and other shell tools. Fairly common tasks like YAML handling is even more of a clusterf. The fact that these tools were all designed to work for their own reasons and not as extensions to a common language isn't their* problem, but it becomes yours if you're trying to deliver a robust and serious piece of software with it. You'll do a lot of DIY around discovering their edge cases and handling them. There are a number of other problems but I think they're lesser in scale, like the lack of a standard way to deliver and use extensions. It's hard to do safe file access. Bats is a pretty good testing framework but no one (including the author of this script) seems to use it. But what I don't really see are many advantages over a regular scripting language, for something like this. The fact that "bash is already installed" is only an advantage as long as your script isn't going to do anything interesting; once it starts doing interesting things, it needs to worry about all kinds of other things being installed. That said, I do think it's a little unfair to tear the author apart over something that really shouldn't be any more ambitious than a cron job doing "git clone https://config-repo/config.git https://config-repo/config.git && config/manage.sh". The fact that they call it an "alternative to Ansible" is a little eyebrow-raising, but I'm sure it is: to them. The question isn't really whether it does what Ansible does, but if you can manage a machine's configuration with a shell script, and of course the answer is yes. But the answer to the question, "Is bash a fine language to write a general-purpose configuration management system in?": the answer is no.

woah 6y ago

It is a pretty sloppy and archaic language. We need an updated version that keeps the string typing and inline execution of external binaries, but has modern syntax, plus a few more conveniences and guardrails.

__MatrixMan__ 6y ago
I was only taking issue with the objection to string typing. I totally agree that the rest of bash requires a bit of stockholm syndrome to love. I haven't yet taken the time to play with it but I'm hoping www.oilshell.org addresses some of the warts.
partdavid 6y ago
You might be interested in Powershell. I used bash for 20 years and considered myself an experienced user and programmer with it. Comparatively, my experience with Powershell is relatively short, but I switched to it and the first time I needed to handle a piece of structured data I was hooked and haven't looked back.
- pnako 6y ago
  I recently discovered Powershell, in a Windows context. It's weird, but has interesting ideas, and is better than bash for sure. Supposedly it supports Linux, but I haven't actually tried.
  - partdavid 6y ago
    It does, and MacOS, and I found that once I changed to bash-style tab-completion and used PSReadLine to get the keybindings I was familiar with, it becomes a pretty comfortable shell. I remove some default shell aliases because PowerShell's notion of file modes and permissions ends up not mapping well, but you have all your normal Unix commands available so it's not really a big deal. Quoting is weird but it's not worse than bash, where quoting is also weird. It's surprising how well objects-as-arguments and objects-as-pipelines work, even when mixing with standard Unix commands. I appreciate standard parameter handling, command naming and I think it pays off on the "Unix philosophy" (small program units doing one thing well) better than bash and shell tools. Those standard approaches produce an aesthetic I didn't like for a long time (Invoke-RestMethod -Url ...) but aliases cut down on your typing (irm instead of Invoke-RestMethod) and I now appreciate the discoverability of standard commands. I keep discovering little gems like default parameter values and the various ConvertFrom-* commands, some from modules.

partdavid 6y ago

I don't disagree with your point, in this context. Bash can be good enough for all kinds of things. Or maybe not. But it's not a simple binary equation--there are tradeoffs that might lead you to it or away from it for a particular situation. I do think there are a few issues that make bash non-robust for this kind of task. If you only look at this through the lens of the "type system", you have a good point about gluing views together, but I think "just strings" is not enough typing. I think I and the industry have had better luck with a base system more like JSON, instead of "just strings". It provides enough structure so that there's a straightforward way to turn wire protocols or other external data into your Java objects or whatever, let dynamic scripting languages handle it in their native base types (which often map pretty well to what JSON offers, while bash really doesn't--note that the author here isn') and are fairly reasonable to manage on their own without special tooling. However, that aside, even if "just strings" were fine for everything, the fact that bash is designed as an interactive shell with barewords for strings really exposes a lot of gotchas for handling data from different sources, just from the sometimes-diabolical problems with quoting and I/O. In the absence of actual function return values, capturing output and storing a process exit code, which might sometimes be the last process's exit or maybe something inside the pipeline if you've set the right global options, is error-prone. It's not robust to hope that the only output coming (on two different output streams) constitutes a complete and correctly-anticipated return value from a subprogram. Errors associated with empty variable values are frequent for this reason. Secondly, bash lacks a lot of features which you need external programs to provide, and the dependency management glue between them is not good. You'll need find, ls, sed, awk (and you may not remember the days with multiple significant Unix platforms and differences in behavior between gawk, nawk, awk-of-different-flavors), cut, sort, ps (/usr/bin/ps or /usr/ucb/ps) all stored in different platform- and environment-specific locations and exhibiting different behaviors without a clear way of constraining your dependencies or even asserting them correctly. In the modern world, you can add to that list curl, jq, parallel, and other shell tools. Fairly common tasks like YAML handling is even more of a clusterf. The fact that these tools were all designed to work for their own reasons and not as extensions to a common language isn't their* problem, but it becomes yours if you're trying to deliver a robust and serious piece of software with it. You'll do a lot of DIY around discovering their edge cases and handling them. There are a number of other problems but I think they're lesser in scale, like the lack of a standard way to deliver and use extensions. It's hard to do safe file access. Bats is a pretty good testing framework but no one (including the author of this script) seems to use it. But what I don't really see are many advantages over a regular scripting language, for something like this. The fact that "bash is already installed" is only an advantage as long as your script isn't going to do anything interesting; once it starts doing interesting things, it needs to worry about all kinds of other things being installed. That said, I do think it's a little unfair to tear the author apart over something that really shouldn't be any more ambitious than a cron job doing "git clone https://config-repo/config.git https://config-repo/config.git && config/manage.sh". The fact that they call it an "alternative to Ansible" is a little eyebrow-raising, but I'm sure it is: to them. The question isn't really whether it does what Ansible does, but if you can manage a machine's configuration with a shell script, and of course the answer is yes. But the answer to the question, "Is bash a fine language to write a general-purpose configuration management system in?": the answer is no.