These files stay deprecated and out of the sourcing path for now, but
apply the same ${var} notation cleanup as the rest of the repo where
it's a pure notation fix. basedir.bash is left untouched: its bug is
a broken escape, not a notation issue, and it mirrors the one already
removed from _helpers.bash.
basedir() had a broken escape ($(dirname \"$-2\") makes no sense) and
was never called anywhere in the repo — it's a leftover copy of the
already-deprecated libs.deprecated/basedir.bash. bashrc already has
its own get_script_dir() for the same need, with proper symlink
resolution.
rc.d/anyenv, rc.d/screen, aliases.d/mc, and rc.d/startx were the last
holdouts still using `which` to check tool availability. Every other
file in rc.d/* already uses `command -v`, which doesn't depend on an
external binary being installed.
Replace bare $var with ${var} everywhere it was still used, matching
the convention already established in rc.d/prompt and rc.d/history.
Positional parameters ($1, $@, $#) and special variables ($?, $$, $-)
are left as-is, consistent with existing usage in _helpers.bash.
rc.d/broot is auto-generated by the broot binary and will likely be
overwritten with its original formatting on the next broot update.
These files are always sourced (never executed directly), so the
#!/bin/bash shebang is inert and misleading. Drop it consistently
across rc.d/*, profile.d/*, and aliases.d/*.
Merge rc.d/mcfly and rc.d/atuin into rc.d/history, following the same
preference-list + availability-check + fallback pattern as rc.d/prompt,
so only one history tool is active at a time instead of both being
initialized independently. Also normalize variable expansions in
rc.d/prompt to consistently use ${var} braces.
Without this, mise is not yet activated when evaluating the prefered
apps scripts and mise installed apps are considered not installed (for
exemple nvim for the EDITOR variable)
Before this:
The bash config repo needed to be cloned in ~/.bash/ to work properly
After this:
The bash config repo can be move anywhere (for exemple in
~/.config/bash).
The create-links.bash helper is adapted to this new behaviour.
So you can clone anywhere and call create-links.bash from anywhere. Then
the symbolic links in your home should be good and the config would load
correctly.
xavier
Xavier Logerais