>
>On Sun, May 19, 2002 at 07:16:08PM -0500, Adam Heath wrote:
>
>
>You are looking at completely the wrong properties. The issue is not
at all
>if a file is a binary, a text file, a picture or a marshmallow from outer
>space. Here are a few hints that should bring you on the right track:
>
>/bin: Executables that should be in the user's (including the
superuser's) PATH.
>/sbin: Executables that should be in the superuser's PATH, but not in the
> PATH of other user's.
>/libexec: executables that should not be in any user's path and that are
> started indirectly by other programs for their own purpose.
>/hurd: executables that can do something useful with the bootstrap port to
> attach themself as Hurd servers to the file system, that should not
> be in any user's PATH, and are started indirectly by settrans or
> the parent filesystem on the explicit request of the user.
>
I see you fighting but you never send new proposals, so I have a New Idea (tm). First of all I will explain some things ; as said before : /lib : contains libraries that are dynamically loaded by programs linked against them. /bin : programs that can be run from the command line. /lib/modules : some sort of special library that has a 'modular' aspect. Since translators *really* are binaries that are /runnable/ from the command line, they should be in /bin BUT it has been explained that it doesn't fit because it is in user's $PATH. Therefore, as translators have some modularity concept (hurd is ALL modular AFAIK) why not putting them in /bin/modules ? (+ /hurd -> /bin/modules for user convenience...). This is right because exec*p() doesn't recurse subdirectories.
JC
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
