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
I’m not sure why you’re bringing the XDG or systemd “standard” into this.
Probably because in their "basedir" specification they do recommend ~/.local/bin to be in $PATH. I'm sure there's more than one distro following that spec, whether you'd consider it standard or not.
User-specific executable files may be stored in$HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX$PATHenvironment variable, at an appropriate place.
1 Introduction # Various specifications specify files and file formats. This specification defines where these files should be looked for by defining one or more base directories relative to which files should be located.specifications.freedesktop.org
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
If I hand write bash scripts, or for those single binary downloads, they'll go into ~/bin. ~/.local is already used by a ton of packages. This helps a ton when it comes to backups or for just finding where I put stuff.
My ~/.local is 283 GB, it's where podman/docker/etc put containers, it may as well be a system managed folder at that point. My ~/bin is only 120 MB and is a lot simpler to backup/restore/sync to other desktops.
it may as well be a system managed folder at that point.
In a way it is. But user-level system, as opposed to root system.
