[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)

From: Richard Kreuter
Subject: Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)
Date: Mon, 18 Mar 2002 18:13:39 -0500
User-agent: Mutt/1.3.27i

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

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]