On Mon, Mar 18, 2002 at 11:35:36PM +0100, Jeroen Dekkers wrote: > On Mon, Mar 18, 2002 at 02:49:21PM -0500, Richard Kreuter wrote: > > On Mon, Mar 18, 2002 at 07:42:56PM +0100, Jeroen Dekkers wrote: > > > > > > Yes, but I can't find a rationale for the /sbin directory. > > > > Maybe there isn't a good one. (It seems to exist (in the FHS, at > > any rate) so that some commands will be out of the way for normal > > users. Given the number of programs on a modern system, though, any > > command the user doesn't already know about is out of the way, in the > > sense that the user will only find it by chance.) > > You mean they have to do "ls /sbin" or have to put sbin in there PATH > manually? Really, I don't think it's a good argument. Why do you want > to hide the binaries?
Normal users under normal system circumstances don't need these binaries, and on other systems mostly can't use them. If they are not useful and not usable, they might as well be omitted from the path directories. > I think the whole /sbin directory is old unix-craft like /usr. If you > move all binaries which can be useful as a normal user to /bin you > don't have much left. AFAICS both the FHS and the GCS allow symlinking > /sbin to /bin. Does anybody see a reason for not doing so? I don't want to defend the /sbin directory any more. An administrator is welcome to modify their systems to his heart's content; we're working on integrating two existing sets of standards, right? Throwing both out might have benefits, but that's not what we're discussing. To answer your question, I can see two: GNU standards compliance, and accordance with FHS rationale and motivation. Richard _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
