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.)

Solved: Thanks a lot for all the feedback and answering my questions! I’ll settle with having my bash scripts somewhere under ~/my_git_monorepo and linking them to ~/.local/bin to stick to the XDG standard.

  • phantomwise@lemmy.ml
    5·
    3 days ago

    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.

    • steeznson@lemmy.world
      1·
      3 days ago

      I dislike having top-level directories in $HOME that aren’t storing media or documents. Some linux ports of games are awful for littering your homedir or Documents. Just lazy devs. Put it all in ~/.local please folks!

      • phantomwise@lemmy.mlEnglish
        2·
        3 days ago

        Oh it’s so annoying when apps put data in .mozilla, .vscode, and .whatevers in the home folder instead of following the specs and splitting it between .config, .local/share and so on… I have 31 .something in my home folder that shouldn’t be there and It’s a cluttered mess. And a few games not even bothering to start the folder names with a dot… 😡

        • steeznson@lemmy.world
          2·
          3 days ago

          I’ll play the game for a while but if they litter my homedir then they are first on the chopping block when I’m looking to uninstall things and free up space.

  • Akatsuki Levi@lemmy.worldEnglish
    311·
    5 days ago

    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

    • BaconIsAVeg@lemmy.mlEnglish
      61·
      5 days ago

      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.

      • Ferk@lemmy.ml
        2·
        5 days ago

        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-level system.

        • BaconIsAVeg@lemmy.mlEnglish
          3·
          5 days ago

          It’s really not. Python virtualenv, Steam, libvirt, composer, krita, vulkan, zed, zoxide, systemd, etc. ~/.local is the domain of various installed packages, not my hand crafted scripts.

    • wolf@lemmy.zipOPEnglish
      51·
      5 days ago

      Another follow up question: Is there any documentation for the linux standard/convention of ~/.local/bin? My initial search about this resulted in nothing which I would call authoritative/definitive.

    • just_another_person@lemmy.world
      3·
      5 days ago

      Mostly this, but also, if you’re going to manage many scripts in a system for many users, revision control doesn’t help that. Either look at packaging them properly for your distro, or using something Ansible to distribute and manage their versioning on the system to make things easier on yourself.

          • Akatsuki Levi@lemmy.worldEnglish
            1·
            4 days ago

            Can’t have supply chain issues if 90% of your stuff isn’t just a bunch of Docker containers running inside a Kubernetes mess

            Not saying that it doesn’t happen on bare metal stuff, but damm, is it a lot more prominent on sources like npm, pip and docker

            • just_another_person@lemmy.world
              2·
              4 days ago

              Well…I mean the biggest obvious example in recent history is the xz-utils hack. There’s probably more like that out in the wild than most want to think about.

    • wolf@lemmy.zipOPEnglish
      2·
      5 days ago

      Thanks! Do you just put the whole .local/bin under source control, do you link your scripts from somewhere else?

  • kittenroar@beehaw.orgEnglish
    1·
    3 days ago

    Local python uses ~/.local/bin, so in the interest of avoiding conflict, it is probably better to use ~/bin.

  • sunshine@lemmy.ml
    2·
    4 days ago

    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

    ) - and (b) I realized it was something I ought to have done a while ago anyway.

    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).

    • wolf@lemmy.zipOPEnglish
      1·
      1 day ago

      Nice! Thanks for chiming in with how Fish does it, sounds like a really great idea to have functions in ~/.config/fish/functions!

    • Laser@feddit.org
      2·
      2 days ago

      I really like fish. It’s just so pragmatic, I don’t know how to describe it differently. No groundbreaking concepts (like nu or elvish), but the tools you need are right there and easily accessible with syntax that doesn’t make me scratch my head (bash).

  • communism@lemmy.ml
    7·
    5 days ago

    I have ~/.local/bin added to my PATH for things i want in my PATH, and ~/scripts for things I don’t want in my PATH. Both managed by chezmoi. I’m surprised if there’s anyone who wants most of their bash scripts in PATH. I only have like 5 scripts in ~/.local/bin; the others get executed on an automated basis (eg on startup or by a cronjob), or so infrequently that I don’t want them in my PATH.

    • wolf@lemmy.zipOPEnglish
      1·
      1 day ago

      My scripts all have a prefix, so I don’t mind having them in my path, they won’t clash with regular commands. This way, when I run a script which gets executed only annually, I can just type prefix- and TAB and will find it.

      • communism@lemmy.ml
        2·
        1 day ago

        That’s fair, but in my case ~/scripts/ acts as my prefix. I suppose that narrows down a lot what your prefix can be though, if it has to be a valid path in which your scripts live.

  • waffle@sh.itjust.works
    5·
    5 days ago

    I’ve tried both and ~/.local/bin tends to be used by a bunch of tools to install their own binaries/scripts so depending on what you use it can become very messy (which did happen in my case). I used to have a ~/Documents/Scripts directory in my $PATH and that was much cleaner than my current setup so that’s what I’d recommend, especially if you want to use Git with it! :)

    • wolf@lemmy.zipOPEnglish
      2·
      5 days ago

      Thank you very much! I was exactly looking for someone telling me that some tools install their own binaries/scripts to ~/.local/bin.

      Most probably I’ll just symlink my scripts from ~/.local/bin then, this would avoid troubles with 3rd partys and most of my dotfiles are symlinked anyway, so the infrastructure is there.

  • ShittyBeatlesFCPres@lemmy.worldEnglish
    43·
    5 days ago

    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.

    • wolf@lemmy.zipOPEnglish
      1·
      5 days ago

      Thanks, I think I get the idea, I just don’t understand the number-prefix, why did you start this convention?

      (Btw.: For some years now I stick to the convention, that everything import is under one sub directory under my home. As long as I have a tarball backup of that sub directory, I am good to lose the whole hard disk w/o fear (e.g. ready for a clean upgrade, distro hop or just go traveling w/o fearing that I forgot to switch off the oven ;-)).

      • ShittyBeatlesFCPres@lemmy.worldEnglish
        3·
        5 days ago

        It’s just alphabetical so the scripts run in the right order. The numbers serve like “A” or “B” except you can add new scripts between one and ten if it comes up and your “10-whatever” file is a mess. It’s sort of a convention on Linux but not everyone does it.

        Then you just add

        for FILE in ~/.shellrc.d/*; do
    source $FILE
done

        To your ~./bashrc (or your preferred shell). Replace shellrc.d with whatever you choose. I use shellrc.d on servers and stuff because the dot d is also kind of a convention for naming folders. People have their own opinions about that but don’t worry about it until you have strong opinions.

        • wolf@lemmy.zipOPEnglish
          1·
          1 day ago

          wow, thanks. I never had the need for scripts running in the right order for my personal scripts, but I remember the old init systems for Linux where this was a thing.

        • ShittyBeatlesFCPres@lemmy.worldEnglish
          1·
          5 days ago

          It just makes it easier to backup your customizations. I copy a lot of my settings in there. I use Vim (which isn’t necessarily the best choice but I’m old) so I just put my .vimrc stuff in my folder. Then you just have to backup one folder and, if nothing else, your CLI will stay the same.

          People argue over emacs and vim (as text editors) and systemd vs init but it’s your machine. That’s part of what makes Linux fun.