friendica.eskimo.com
For one user account, I want to have some bash scripts, which of course would be under version control.
The obvious solution is just to put the scripts in a git repository and make ~/bin a symlink to the scripts directory.
Now, it seems on systemd systems ~/.local/bin is supposedly the directory for user scripts.
My question, is mostly, what are the tradeoffs between using ~/bin and ~/.local/bin as directory for my own bash scripts?
One simple scenario I can come up with are 3rd party programs which might modify ~/.local/bin and put their own scripts/starters there, similar to 3rd party applications which put their *.desktop files in ~/.local/applications.
Any advice on this? Is ~/.local/bin safe to use for my scripts or should I stick to the classic ~/bin? Anyone has a better convention?
(Btw.: I am running Debian everywhere, so I do not worry about portability to non systemd Linux systems.)
It is better NOT to put them in system directories since those will get overwritten by upgrades.
That's a purely Atomic thing, isn't it?
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/binThis 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:.which wolf_bin will show them the full path to the script. So really, the location does not matter much.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.
This tool is used to install `pyenv` and friends. Contribute to pyenv/pyenv-installer development by creating an account on GitHub.GitHub
