multiple boot strap files, including with os/template matching

[xenoterracide]

I think yadm should just load all files that because with bootstrap starting with bootstrap itself, but continuing with the same order as an etc.d directory (or maybe there should be a bootstrap.d) obviously I could probably just do this myself, but the killer feature that makes that harder is wanting to have files that only execute on certain OS's, I figure the extension ##foo though I wish we could do file##foo.sh for syntax highlighting. I do know their are other simple ways to accomplish this, I could simply write the loop myself, and probably will consider it for now. I could have the templates install another file based on OS :P.

[erijo]

Put the files in your bootstrap.d directory and use the regular alternate mechanism like: work.sh##c.work. Then have your bootstrap script run all bootstrsp.d/*.sh files. That should then only run the files that apply to the current machine.

To get syntax highlighting to work you can, with 3.0.0, name the files work.sh##c.work,e.sh

[xenoterracide]

oh cool, can't wait until the 3.0.0 update comes to AUR. wait the alternate syntax will already work in that directory?.

[erijo]

According to https://aur.archlinux.org/packages/yadm it's already there.

You can use the alternate syntax in any directory tracked by yadm.

[xenoterracide]

huh, didn't know that, pretty sure it wasn't last night when I was updating stuffs

[xenoterracide]

hmm.. I don't see this stuff documented on the alternates or templates page.

and use the regular alternate mechanism like: work.sh##c.work
You can use the alternate syntax in any directory tracked by yadm.

but how does it know where the files go? afaik there's no header to define location, so I kind of assume in this case the path for the alternates would have to be

❯ vi ~/.config/yadm/alt/.config/yadm/alt/bootstrap.d/package-manager.sh##os.Linux

[erijo]

I was thinking something like this:

Let ~/.config/yadm/bootstrap contain e.g.:

#!/bin/sh

BOOTSTRAP_D="$HOME/.config/yadm/bootstrap.d"

if [ ! -d "$BOOTSTRAP_D" ]; then
    exit 0
fi

cd "$BOOTSTRAP_D"

if [ "$(echo *.sh)" = "*.sh" ]; then
    exit 0
fi

for bootstrap in *.sh; do
    test -x $bootstrap && ./$bootstrap
done

The create the files you want to run, e.g.:

• ~/.config/yadm/alt/.config/yadm/bootstrap.d/package-manager.sh##os.Linux,e.sh
• ...

Make sure that bootstrap and all files in bootstrap.d are executable. Also add and commit them with yadm.

I haven't actually tested the above, but I think it should work.

[rasa]

test -x will return false if presented with a filename *.sh, so the above could be simplified to:

#!/bin/sh
: "${HOME:-~}" # set HOME to ~ if not defined
BOOTSTRAP_D="$HOME/.config/yadm/bootstrap.d"

for bootstrap in $BOOTSTRAP_D/*.sh; do
  if [ -x "$bootstrap" ]; then
    cd "$HOME" || exit # to quiet shellcheck
    "$bootstrap" || exit
  fi
done

I think bootstrap scripts expect to be run from the home directory, so I added the cd command.
Also, my guess is users will expect that if any bootstrap script fails, processing is aborted, so I added || exit.

[erijo]

I think bootstrap scripts expect to be run from the home directory

True. Or more so I think they are expected to be run from the same directory as the main bootstrap script (which may be different from $HOME).

Also, my guess is users will expect that if any bootstrap script fails, processing is aborted

Another good point. Thanks @rasa!

I put together something more "official" and submitted it in #287 as a contrib bootstrap script. It uses $BASH_SOURCE[0] instead of $HOME/... so that it can support any $YADM_DIR setting. I've also added a sort so that the scripts are run in a controlled order and made it possible to keep the template files in the bootstrap.d directory directly instead of forcing them to be in the alt dir.

[erijo]

@xenoterracide: are you happy with the bootstrap script that's now available in the contrib directory?

[xenoterracide]

it's fine, though I wonder if it should make the missing directory instead of error, but that's not a big deal to me, and probably makes debugging easier. Also not sure if mkdir works on windows these days...