I'd imagine it's because it's available everywhere (even openwrt routers and those things), and it's easier to get away with not having to use sudo (depending on the task you are doing, of course). With Ansible, you almost always need python installed on the target host. Which, in 95% of cases is not a problem. It's not ideal to install a system package just because you want to do some provisioning (there are ways around that, but it gets hacky pretty quick...).

I haven't looked at this yet, but I really like the idea. Always wanted to have something like this for a few special cases. And if it's well designed, it could be a nice, lightweight and portable solution to do server provisioning, development project setups, use in Docker builds, etc.

> it's available everywhere (even openwrt routers and those things)

BASH itself? Or a Bourne-family shell? I thought most embedded systems were shipping busybox's ash as /bin/sh

Most *nix server and cloud nodes use bash for the shell. You're right about embedded systems but they're not usually the target platform for a config management system like this one or Ansible.

Yeah, I was mostly thrown by the reference to openwrt. I'm sure most/all GNU/Linux systems ship BASH.

Debian ship's dash for /bin/sh doesn't it?

but also ships bash for interactive use, so #!/bin/bash will just work, which you should be doing anyways in scripts that want bash.

If you use `env` instead, it'll pick up more recent versions of bash available on the path, such as the one installed by homebrew

    #!/usr/bin/env bash

/usr/bin/env bash?

It's common even for embedded systems which use busybox to provide /bin/bash because bash itself is not that large.

In my experience, Perl is available everywhere. Some sort of bourne shell is likely available everywhere, but Perl is a safe bet. (EDIT: actually, some systems have recently started removing Perl from their base I hear... Fedora?)

Neither are available on common small embedded systems that rely 90% on busybox.