2

I am reading up on several commands, some of which are privileged and some that may or may not be installed. My system (gentoo) will respond with command not found sometimes when the program in the system. How do I match the behavior of something like emerge?

Example of behavior I would like:

$ emerge -av mypackage
This action requires superuser access...

What I currently have:

$ lspci
bash: lspci: command not found
$ sudo lspci
00:00.0 Host bridge: ...

I would even prefer a "permission denied" message so I know that I should try to use sudo. Of course I don't want to be experimenting around running as root.

Improve this question
2
  • 2
    I would like to say that the reason that lspci is not found is because /sbin and /usr/sbin are not in your $PATH. However, my lspci is in /usr/bin and I can execute it as an unprivileged user. Probably a better example would be /sbin/ifconfig which actually needs root permissions to do anything useful except list the interfaces. The gist of what I am saying is that the commands that usually need root permissions are supposed to be placed in the sbin directories, and the sbin directories are not supposed to be in the PATH of underpriv users.
    – umeboshi
    Feb 4, 2015 at 14:30
  • @umeboshi lspci and/or lsusb (can't remember which one..) do need root privileges for some options. The default (no parameter) output does run fine as a normal user though...
    – Gert van den Berg
    Feb 4, 2015 at 14:56

2 Answers 2

Reset to default
2

The directory containing lspci is likely not in your PATH.

You can find its location using sudo -i which lspci and add the directory to your path.

The likely locations are /sbin or /usr/sbin

To add them you your current PATH, you can run (in a Bourne-based shell) export PATH="$PATH:/usr/sbin:/sbin"

To make the change permanent, add the export command to your .bashrc or .bash_profile (assuming you are using bash as a shell)

Improve this answer
9
  • I was thinking the same thing, but lspci is in /usr/bin on my system and doesn't need root privileges. Also it's generally not good to add the sbin's to a underpriv's PATH. The sudo command will do that for you if /etc/sudoers is configured correctly. The whole purpose of the sbin directories is to separate the commands that need root from the other commands.
    – umeboshi
    Feb 4, 2015 at 14:33
  • if lpsci is not on the user's path, sudo which lpsci will not show you the path, since the PATH is defined in root profile that sudo do not load in this notation. Assuming lpsci is present in the system and is available for root session, the way to know its path for user is su -l -c '$(which lpsci)' to know the path to
    – Tagwint
    Feb 4, 2015 at 14:37
  • Keeping {,/usr}/sbin/ out of the PATH doesn't do anything for security (unless using a restricted shell) - the user can run the command manually anyway (using a full path). I would not add them to the start of $PATH though, since /sbin traditionally contained potentially limited version of commands, in case /usr doesn't mount. On RHEL5, lspci is in /sbin/lspci.
    – Gert van den Berg
    Feb 4, 2015 at 14:38
  • @Tagwint: It does work for me however... (Tested on RHEL6) I'm assuming that if the PATH changes to allow running lspci with sudo, it will change for which run from sudo as well... (Yours does seem like a more generic solution..) (su tend to have different password requirements, which is problematic on systems without root passwords..) (sudo -i might be easier for sudo users)
    – Gert van den Berg
    Feb 4, 2015 at 14:43
  • 1
    @umeboshi Interesting... (I'm normally an Arch user, where someone decided it is a good idea to merge /bin, /usr/bin, /sbin and /usr/sbin...) (Semi-related: Solaris have /bin as a link to /usr/bin, but it also have hundereds of /usr/*/{s,}bin directories) The annoying part is that several /sbin utilities are quite functional for non-root users. (And packagers mainly control where things go, likely within a policy though)
    – Gert van den Berg
    Feb 4, 2015 at 15:12
1

lspci isn't found because it isn't on an ordinary user's command search path. Commands that can only rarely or never be used effectively by non-root users are placed in one of the directories /sbin, /usr/sbin or /usr/local/sbin, which are in root's command search path but not on other users'.

You can configure what bash does when a command is not found by defining a function called command_not_found_handle. So you can put something like this in your .bashrc:

command_not_found_handle () {
  if [[ -x "/sbin/$1" || -x "/usr/sbin/$1" || -x "/usr/local/sbin/$1" ]]; then
    echo 1>&2 "bash: $1: command not found, but can be executed as root"
  fi
  return 127
}
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .