Could have called it "Baby Got Bash"
It sounds like it's intended to rhyme with "stirred" and not "starred." The latter, intended as a slur is unacceptable (imo), but the former?
As a person who has less hate than most people about bash; there are better options.
I understand the frustration with ansible, with DSLs in general and the slow creep they all take to becoming proper languages with loops and conditionals- only with worse semantics than real languages.
But this isn’t the way.
Shell semantics are terse and powerful, single character changes can completely alter the control flow of a sequence and can be very difficult to follow.
Managing data structures is also full of foot guns.
I don’t want to be too specific because you can “get around” a lot of issues if you know what you’re doing, the problem is that it’s very easy to introduce subtle bugs and not know about them for a long time- or that you can introduce bugs and not understand how or why.
Shell works great for piping together series of text and running commands in sequence and conditionally; but once you’re at the point where you’re parsing config files to do control flow and you’re sourcing more than a handful of files then controlling the quality of the script becomes very difficult.
Personally, I’ve written 100kLOC bash, I’m very comfortable with the semantics, but I still get tripped up sometimes because of some weird quirk that is not widely understood.
It can stream shell commands so you've got all the usual sed awk etc
And has a battle tested OS detection logic built in.
>This value is correct for Debian and derivatives, but not for my Gentoo or FreeBSD systems, so I’ve created OS-specific configuration files for these.
And can copy in different templates depending on OS.
Hell it can even detect whether its in a KVM or LXC or metal environment with right helpers and same for architecture so very useful for building a script that works in a very mixed environment
Still to each their own. I occasionally feel the need to reinvent a specific wheel too.
> It can stream shell commands so you've got all the usual sed awk etc
I can write a couple lines of yaml which includes the line of sed/awk/whatever, or just write the one line of sed/awk/whatever.
> And has a battle tested OS detection logic built in.
You can get pretty far with just checking /etc/os-release, and you'll need only a fraction of the code Ansible brings to do that. Ansible might do a _slightly_ better job, but the increased complexity is definitely not worth it.
> And can copy in different templates depending on OS.
Yes, it can do this, and I have done this. It's a lot of boilerplate YAML you'll need _every_ time you want to write any playbook. It's just not worth the ridiculous amount of hoop-jumping for something which seems to me to be a rather straightforward use case.
You can wrap anything in ansible basically, including stuff that isn't idempotent.
Some of their modules are definitely conducive towards achieving it though.
IMHO it's better to have no guarantee than a vague suggestion that you might tend to rely on but then be bitten because there's nothing actually enforcing the guarantee.
That way they could write everything in a much nicer language and still not require a dependency. For such simple scripts the relatively low performance of these embedded scripting engines would be a non-issue, and you could even provide domain-specific utility functions (e.g. for shelling out, sending http requests or otherwise interacting with the system) implemented in the the host language (Rust/Go) with full access to their library ecosystems...
One way to think about m4 is as form-substitution, eg. the ssh-config customization via sed.
Another is as text generator, eg. the classic sendmail config generator, where one writes m4 succinctly which in turn generates complex files.
From a 10,000 meter perspective, all the managed servers' config files are a projection from the central config repository. If that config is already an m4 file, then all that's left is finding the variant configs and handling them.
`make` is another nicety, as it handles the dependencies, eg. scp'ing the config and then HUP'ing the daemon only when that config changes.
> At some point people have to own their own misperceptions.
I don't have to own shit. I didn't name it.
So. There.
