From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: Thu, 31 Mar 2005 16:14:54 -0600
In article <firstname.lastname@example.org>, Scorp123 wrote:
>On Fri, 04 Mar 2005 12:13:04 -0800, Perfect Reign wrote:
A little slow on the responding? ;-)
>They are not in your $PATH environment variable. The command shell
>will only look for programs in /sbin when you are logged in as "root", a
>normal user has no business starting programs from there. "sbin" stands
>for "Superuser's BINaries", so that's why :-)
No - the Filesystem Hierarchy Standard infers the S is System. See section
3 of that document. The /sbin directory is not part of the original UNIX,
but was added in System V Release 4 (SVR4) as a common place to stash
system binaries. Another definition indicated this was where statically
compiled binaries were to be placed. Normal users may have need for some
of the commands in /sbin/ - certainly as a network administrator, I'm
constantly using /sbin/arp, /sbin/ifconfig and /sbin/route to read the
contents of the arp table, network interface statistics, and the routing
>> As regular user...
>> kai@yoda:~> /sbin/ifconfig
>> bash: /sbin/ifconfig: No such file or directory
>Yeap. As I said, you probably don't have it in your $PATH variable and
>hence your shell never looks for "ifconfig" inside the "/sbin" directory.
Nope - PATH has nothing what-so-ever to do with that. He provided the
full path to the command in the command line, so the PATH environment was
not consulted. 'man bash' and look at the section 'COMMAND EXECUTION'.
Here, the shell is saying that the file doesn't exist (if it existed and
he had no execute permission, or no permission to the /sbin/ directory,
he should get the error "bash: /sbin/ifconfig: Permission denied" instead).
Try it and see.