On Tue, 31 Oct 2000, Sean 'Shaleh' Perry wrote:
> On 31-Oct-2000 Krzys Majewski wrote:
> > I have a habit of writing many shell scripts for everything. Some of
> > them are very local to me, so I put them in ${HOME}/shell and stick
> > that in my PATH. Some of them may be generally useful, so although I
> > don't have any users, I'm anal, and I put them in /usr/local/sbin/. I
> > don't know what the "s" stands for, maybe "system"? This location
> > works well enough except locally compiled system software may also put
> > stuff there, in which case we have both binaries and sh scripts in the
> > same directory, is that OK? Any better suggestions? -chris
>
> bin (whether bin or sbin) is more correctly name "executable". If you look
> in /usr/bin or /usr/sbin you will find sh, perl, awk, python, etc scripts.
>
> If it is a system maintenance script or one that should be run by admins,
> sbin is the way to go. Otherwise, it belongs in bin. You will note that
> /sbin and /usr/sbin or rather small compared to /bin and /usr/bin. Also
> sbin directories tend not to be in the average user's path.
I think bin is short for binaries, in the generic sense of executables. I
think in the dim and distance past from the early days of Unix, sbin meant
'static binaries'. That is, binary executables that would run without having
to load any external libraries. /sbin is where you would keep the set of
critically essential tools you might need to put your system back together
after a disaster like a disk crash. Things like fdisk, fsck, lilo, etc.
/usr/sbin tends to have the really important system administration tools like
passwd, and security-sensitive system executables like inetd. These are all
also executables which could lead to problems in the hands of inexperienced
or malicious users, so those directories are usually not accessible to anyone
but root.
Current practice seems to have strayed a bit from the concept of only having
statically linked binaries in the sbin directories. You may find shell
scripts, perl, python, all kinds of stuff. I think these days a lot of
people tend to think the 's' stands for system or sysadmin or some such. And
you may find things in there that don't even relate to system administration.
I think it could be argued that those changes are not necessarily good from
the standpoint of system security.
--
Bud Rogers <[EMAIL PROTECTED]>
