🚀 go-pugleaf

Jorgen Grahn <grahn...@snipabacken.se> writes:
>On Wed, 2018-06-06, Grant Taylor wrote:
>> On 06/06/2018 07:13 AM, Kerr-Mudd,John wrote:
>>> Having come from the "simpler" DOS world of total control, with maybe 
>>> just a path to c:\utils, I found it a puzzle that there were so many 
>>> places (yet only those ones!) to put executables under linux.
>
>It's a bit puzzling, but not a problem in practice.
>
>> You can put executables in a LOT of places.  You just need to choose 
>> somewhere that's already in the PATH environment variable, or modify it 
>> to your liking.
>
>I'm happy I don't see a lot of software installed under /opt anymore.
>That was a pain: often as a user I had to add /opt/$foo/bin to my
>$PATH, for each piece of software $foo I was interested in.  And quite
>often such software needed other environment variables like $FOO_PATH
>too, or it would malfunction.
>
>There's also the issue with documentation.  If a piece of software is
>in your path, but the man command cannot find the manual page, you're
>in an awkward situation.  man(1) on Linux nowadays has the option to
>search for man pages in $foo/man/ if $foo/bin is in the $PATH, but I
>think that's a recent improvement.

All man utilities have supported $MANPATH since basically forever.

e.g. from SVR4 man.c:

main(argc, argv)
        int argc;
        char *argv[];
{
        char section, subsec;
        char *mp;
        char *cmdname;

        int mrc; /* manual() return code */

        /* If defined, use environment value as default manual path list. */
        if ((mp = getenv("MANPATH")) != NULL)
                manpath = mp;

>
>> I personally have ~/bin first in my path.
>
>It's unclear to me if that's standardized, but yes, I make sure I have
>that in my $PATH, too.  It's where all scripts go that are only
>interesting to me.

It only needs to be at the _front_ of $PATH if you intend to
override utilities of the same name that exist under earlier
entries in $PATH.