Personally, I put a ~/.get-going or whatever you want to call it and put all my scripts in there. Name them with numbers first like “10-first.sh” “20-second.sh” and then just put a line in .bashrc or .zshrc or whatever you like. Aliases and any critical stuff last. Then one line in your rc file can include them all.

I made some bash scripts for distro-hopping that are now [undiscloded] years old so I can basically backup a few folders — the second being ~/bin where I put AppImages and stuff and sometimes ~/Development (I don’t always need the dev one because backups of those exist as repos) folder if I need to reinstall. A lot of people backup their whole home directory. But I prefer my method and that’s why we use Linux. I don’t want my settings for every app coming with me when I go on a new journey. Choose your own adventure.

Neither ~/bin or ~/.local/bin are part of most shell's default $PATH so you're going to have to modify the user's shell profile (or rc) to include it. It's possible that your favorite distro includes it but not mine. For example(s):

﬌ unset PATH                                             

﬌ /bin/bash --noprofile --norc         
bash-5.2$ echo $PATH
/usr/local/bin:/usr/bin

﬌ unset PATH

﬌ /bin/zsh --no-rcs --no-global-rcs
Sinthesis% echo $PATH
/bin:/usr/bin:/usr/ucb:/usr/local/bin

﬌ ls -l /bin
lrwxrwxrwx. 1 root root 7 Jan 23  2024 /bin -> usr/bin

This is on Debian

Sinthesis@debian:~$ /bin/bash --noprofile --norc
bash-5.2$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

That said I would go with one of these two options:

1) Make a package for your distro. This may be overkill for a couple scripts but you did say they're in a git repository so you could automate it. The package would install to /usr/bin which would require sudo or root. If the scripts are only allowed to be run by one user, set the rwx and group permissions.

2) A pattern I like, especially for lightweight things such as scripts that don't require compiling or OS management and also are using git; a "hidden" or "dot" directory in the user's home where the repo lives e.g. ~/.lemmywolf/ Then add scripts directory to the user's $PATH e.g. PATH=$PATH:~/.lemmywolf/scripts. This is what some fairly large projects like pyenv or volta do. You could take it a step farther and modify this installer script to your liking github.com/pyenv/pyenv-install…

/edit 20 year Linux user (Redhat AS2.1) and 5 years of Unix (HPUX & Solaris) before that.

/edit2 I just noticed the pyenv-installer does not modify the user's shell profile. That could easily be added to the script though.

pyenv-installer/bin/pyenv-installer at master · pyenv/pyenv-installer

This tool is used to install `pyenv` and friends. Contribute to pyenv/pyenv-installer development by creating an account on GitHub.

^GitHub

I use ~/.local/bin since by linux standard, ~/.local is a user-level /usr/local, which is a override level of /usr

~/bin ends up cluttering the home folder

Personally I put scripts in ~/.local/bin/scripts/ instead of just ~/.local/bin/ because I like to keep them separate from other binaries. To note: even though ~/.local/bin/ is in PATH, it's subfolders are not, so if you do that you need to add the scripts subfolder to PATH if you want to run the scripts directly.

Well actually my scripts are in mydotfilesrepo/home/.local/bin/scripts, and I use GNU Stow to symlink mydotfilesrepo/home to /home/myuser/ (same for mydotfilesrepo/etc/ and mydotfilesrepo/usr/ which are symlinked to /etc and /usr), but it's the same result. Stow is pretty cool for centralizing your configs and scripts in one repo !

I've never seen ~/bin before so I can't comment on whether it's a good idea.

I migrated to fish recently and at first I was really annoyed that I had to decompose my ~/.bash_aliases into 67 different script files inside ~/.config/fish/functions/, but (a) I was really impressed with the tools that fish gave me to quickly craft those script files (-

~> function serg
    sed -i -e "s/$1/$2/g" $(rg -l "$1")
end
~> funcsave serg
funcsave: wrote ~/.config/fish/functions/serg.fish

Anyway, all this to say that fish ships with a lot of cool, sensible & interesting features, and one of those features is a built-in place for where your user scripts should live. (Mine is a symlink to ~/Dropbox/config/fish_functions so that I don't need to migrate them across computers).