Hey I want to add a command to my system. I am not using any package-format or anything. I just want to install a script that I wrote.

I know of some ways to do that:

  • add my script into whatever is the first thing in $PATH
  • add a custom path to $PATH (in /etc/profile.d/ or /etc/environment) and put the script into the custom path
  • add my script into /usr/bin or /usr/local/bin

I remember reading that profile.d/ doesn’t get picked up by all shells and that /etc/environment (which exists but is empty on my system) shouldn’t be used.

What should I do to ensure that my command will be available everywhere on any gnu/linux or bsd system?

EDIT: I should clarify that I am asking this only out of curiosity. I just like knowing how this stuff works. The script was just an example (I thought this would make it easier to understand, lol). I am interested in knowing a way to install a command without any chance of that command later not being found by other programs. I find many different answers to this and they all seem a little muddy, like “doing x should usually work”. I want to know the solution that always works

  • niemand@discuss.tchncs.deOP
    31·
    1 year ago

    So are you saying that /usr/local/bin exists on every gnu/bsd system and when I put a script in there it will always be available for all users, without any chance of this not working (eg. “command not found”) and no need to reboot my computer or anything? Also, is there a good reason not to put it in /usr/bin?

    • folkrav@lemmy.ca
      91·
      1 year ago

      He just told you why not to put it in /usr/bin: it’s where your package manager puts executables.

      I’m not too sure why it’s important where your users put your script from a script author perspective? Otherwise, just check the default $PATH content for a fresh user on said system, and put it somewhere in there.

      • niemand@discuss.tchncs.deOP
        6·
        1 year ago

        He just told you why not to put it in /usr/bin: it’s where your package manager puts executables.

        I thought he might tell me why me and my package manager cant both use this directory. The reason for that is not obvious to me

        • chickenf622@sh.itjust.works
          5·
          1 year ago

          Cause it’s good to know of something is an installed package at a glance. I also imagine it would reduce the risk of accidentally overwriting your own scripts if the packages happen to have the same name as your local scripts.

        • aperson@beehaw.orgEnglish
          4·
          1 year ago

          Because in situations like this, segregation is a good thing. You don’t want automated tools futzing in directories that you might have wanted to keep as-is.

        • folkrav@lemmy.ca
          4·
          1 year ago

          Other people already answered you, but it’s mostly for:

          1. Keeping things obvious, you know who did what
          2. Avoid potential collisions
        • InverseParallax@lemmy.worldEnglish
          2·
          1 year ago

          Unix has had a long running convention of separation between “operating system” and other files, so you can blow away something like /opt or /home without making your system unbeatable.

          If you stick stuff under /usr/bin then you have to track the files especially if there are any conflicts.

          Best to just add another path, I use ~/bin because it’s easy to get to and it’s a symlink from the git repo that holds my portable environment, just clone it and run a script and I’m home.

          • andruid@lemmy.ml
            2·
            1 year ago

            And migrate /opt and /home (or even remotely mount) so that user data is preserved outside of the system!

            Both features make system admin much more sane!