The strangeness called `sbin'

Warner Losh imp at bsdimp.com
Thu Nov 10 17:42:02 UTC 2011


On Nov 10, 2011, at 10:16 AM, Ed Schouten wrote:

> Hi Peter,
> 
> * Peter Wemm <peter at wemm.org>, 20111110 17:56:
>> Of course, that pales in comparison to the impact of adding
>> /usr/local/bin to the path, but it does show this does have potential
>> user visibility.  And there's also the issue that most most users add
>> every possible directory to their $PATH anyway.
> 
> Exactly. Also, there are shells nowadays that cache all binaries in PATH
> up front, such as zsh. When they start, they loop through all dirents in
> all directories in $PATH and add it to a big cache. This entirely
> defeats this purpose.

tcsh and csh before it has been doing this since the 1980's, so it is nothing new.  Add a new binary to your path and forget to rehash: you can't run it.

> I don't think that there are that many people who don't add /sbin and
> /usr/sbin to $PATH nowadays. I have colleagues of mine who use Linux
> systems that don't have this in their $PATH. When I ask them whether it
> causes problems for them, they deny, but it turns out they simply put
> `sudo' in front of it, to work around that, regardless of whether it was
> needed.

Folks that grew up before the "all the world is a vax^W^Wruns Linux" have it in their path, but younger colleges generally don't have it unless they've been forced to use Solaris or *BSD at some point.

>> Is it really worth it though?  Perhaps fix the couple of oddball cases
>> instead? (eg: md5, lastlogin and friends). ac used to require access
>> to privileged files due to privacy concerns on shared user systems.
> 
> I think if we have to look at each tool and re-examine whether they
> should be in bin or sbin and convert them to do so, it would take
> approximately the same amount of investment as moving them into a single
> place. And I am willing to do that. :-)

I'm a bit torn here.  It would be nice to have one, unified place for binaries.  Do embedded systems really need to burn the extra inodes on sbin, libexec, etc?  No, they don't.  On the other hand, these paths seep into so many places that I gave up my attempts years ago to just put all the files in one place (I didn't like the symlink idea because I worried about shells that were stupid and put all entires into their hashes multiple times).

I'd honestly start small here with (1) move the ones that are obviously wrong (and aren't specified by posix to be wrong). (2) make it an option to just make one or two binaries directories with compat symlinks (because there's a ton of scripts that just know where binaries life).

Warner


More information about the freebsd-arch mailing list