Worth noting that this is GNU-specific! For macOS for example, you’d have to install GNU userland (e.g. from homebrew) to get the flag. There’s still value in using other solutions (such as ln), portability-wise.

As an aside: I mostly think of the ln param orders as exactly the same as cp and mv:

cp FROM TO
mv FROM TO
ln [-s] FROM TO

Maybe that could help!

If we’re talking specifically about executable scripts, here is #bash’s (libera.chat) factoid on the matter:

Don’t use extensions for your scripts. Scripts define new commands that you can run, and commands are generally not given extensions. Do you run ls.elf? Also: bash scripts are not sh scripts (so don’t use .sh) and the extension will only cause dependencies headaches if the script gets rewritten in another language. See http://www.talisman.org/~erlkonig/documents/commandname-extensions-considered-harmful

It’s for these reasons that I keep my executable scripts named without extensions (e.g. install).

I sometimes have non-executable scripts: they’re chmod -x, they don’t have a shebang, and they’re explicitly made for source-ing (e.g. library functions). For these, I give them an extension depending on what shell I wrote them for (and thus, what shell you need to use to source them), e.g. library.bash or library.zsh.

Right! Recursive is implied by -a

Yep. There’s a single ./install script in project root that calls install-cfg and install-plugins. I only really need to run it once (first time I set up on a machine), and every time I add a new file. If all I’ve done is update existing files, a simple git pull will update my dotfiles’ content automatically, as everything is symlinked already.

I agree with @glad_cat@lemmy.sdf.org, all of these are just different ways to skin the cat. Whatever gets the files in the proper directories. Once you pick one (even arbitrarily, to a degree), you’ll very likely find no reason to push you toward another solution. I myself use symlinks with GNU cp -s

There had been posts here, but we might be getting hit with this issue: https://lemmy.sdf.org/post/602126

Quite a few times, sure. git bisect is a specific case of a more general technique – binary search fault localization – which comes in handy every once in a while (you can go a long while without needing it, but when you do need it, you’ll be thankful for it). If you can’t otherwise trace where in the code something is going wrong, bisect the code: comment or remove half of it out, see if it reproduces (therefore localizing it to either the removed or the remaining half), and repeat. If you’re working with some software that’s breaking on your config after a major version bump, bisect your config. Don’t have an idea what introduced a bug into your branch? git bisect.

Happy to be here!