Date: Thu, 10 Nov 2011 10:38:21 -0700 From: Warner Losh <imp@bsdimp.com> To: Ed Schouten <ed@80386.nl> Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' Message-ID: <C9C138D1-40CC-4B0C-B5A3-4E69EB61806A@bsdimp.com> In-Reply-To: <20111110171605.GI2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <CAGE5yCr3BzWzwOAqo7wifgUTRC%2BG=2o4bDmk9H-%2BCxr=zJqYmw@mail.gmail.com> <20111110171605.GI2164@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 10, 2011, at 10:16 AM, Ed Schouten wrote: > Hi Peter, >=20 > * Peter Wemm <peter@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. >=20 > 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. >=20 > 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C9C138D1-40CC-4B0C-B5A3-4E69EB61806A>