3 ms·

> This is similar to installing something under /usr/sbin/ As someone who's trying to get to grips with the Linux filesystem conventions, would you mind elabor

by scubbo 5y ago

> This is similar to installing something under /usr/sbin/ As someone who's trying to get to grips with the Linux filesystem conventions, would you mind elaborating on a) why that's wrong, and b) what you would suggest instead? This reference[0] suggests that `/usr/sbin` is for "general system-wide binaries with superuser (root) privileges required" (and `/usr/bin` for those that don't require root privileges). I've therefore been using them in my homelab for binaries like the Cloudflare Tunnel Client[1]. Where instead should I have installed it? * If to a "well-known location" that is commonly-used by convention, how should I find out what that is? * If to a custom location of my choosing, how should I communicate its location to scripts/tools that _use_ that binary? I see later in your comment that you suggest "Add whatever folder to the user's PATH environment variable to make it easy to run.", but that doesn't seem like a scalable solution for a multi-user environment? [0] https://askubuntu.com/a/308048 https://askubuntu.com/a/308048 [1] https://github.com/cloudflare/cloudflared https://github.com/cloudflare/cloudflared

Nullabillity 5y ago
Generally, `/usr` is for stuff packaged by your distribution, while `/usr/local` (so, `/usr/local/bin` and so on) is for your own custom stuff. Both the `/usr` and `/usr/local` equivalents will be on your $PATH by default in most distros. For stuff that isn't just a self-contained executable, consider installing it to the folder `/opt/$MY_APP` and either symlinking the main binary into `/usr/local/bin` or putting a wrapper script in there (if the thing doesn't like being symlinked outside of its primary install dir). The wrapper can be as simple as: #!/bin/sh exec /opt/my-app/bin/my-app "$@"
- scubbo 5y ago
  Thanks! This helps a lot!
charcircuit 5y ago
/usr/sbin is a legacy artifact that shouldn't be used. /usr/sbin is usually just symlinked to /usr/bin
- scubbo 5y ago
  This was not a helpful reply because it only told me what not to do, without providing a better alternative. The sibling comment is much more helpful.

by scubbo 5y ago

Nullabillity 5y ago

Generally, `/usr` is for stuff packaged by your distribution, while `/usr/local` (so, `/usr/local/bin` and so on) is for your own custom stuff. Both the `/usr` and `/usr/local` equivalents will be on your $PATH by default in most distros. For stuff that isn't just a self-contained executable, consider installing it to the folder `/opt/$MY_APP` and either symlinking the main binary into `/usr/local/bin` or putting a wrapper script in there (if the thing doesn't like being symlinked outside of its primary install dir). The wrapper can be as simple as: #!/bin/sh exec /opt/my-app/bin/my-app "$@"

scubbo 5y ago
Thanks! This helps a lot!

charcircuit 5y ago

/usr/sbin is a legacy artifact that shouldn't be used. /usr/sbin is usually just symlinked to /usr/bin

scubbo 5y ago
This was not a helpful reply because it only told me what not to do, without providing a better alternative. The sibling comment is much more helpful.