In comp.sys.raspberry-pi,
Martin Gregorie   wrote:
> FYI the convention is that locally developed programs should go in /usr/
> local/bin if they are for anybody to run and /usr/local/sbin if they
> should only be run by root. because these directories are defined in the
> $PATH environment variable by default.

I've noticed some new systems, eg Ubuntu 16's bash, go a step further
and add $HOME/bin (very traditional) and $HOME/.local/bin to the PATH.
What's with the second one? I've (on multi-user systems) used a scheme
like:

   PATH=$HOME/bin:$SYSTEM_PATH:$HOME/usr/bin

Where the things in $HOME/usr/bin are stuff I've compiled myself, but
I'd prefer a system one if it comes along; and the things in $HOME/bin
are programs for which I always want mine to "win". Is the .local/bin
thing something similar?

> BTW, did you spot a major difference between Linux and Windows when a
> program is searching for files supplied as command line parameters?
>
> For a program running on Linux the base directory for finding a file is
> your current working directory but on Windows it is the directory holding
> the executable.

You were directing that at someone else, but I don't think that ever
sunk in with me, except for library path stuff. This is a symptom of my
infrequent use of Windows.

> As a consequence its a good practise to write programs that have a
> configuration file to look for it first in '.' (the current working
> directory), then in /usr/local/etc and finally in /etc because this lets
> you test the program in your development user with a test configuration
> file in the same directory and then, in production, put its default
> configuration file in /usr/local/etc so users with special needs can keep
> their configuration in their own directories.

I'm not in favor of things searching for configuration in the *current*
directory by default. That way leads to surprises. My feel for a "unix
like" search path for configuration falls under two modes of thought.
If a program will use a single configuration file (but allowed for that
configuration file to include other files), then it should be

   1. The *last* conf file specified on the command line
   2. If no command line file, then the conf file specied by environment
      variable
   3. If no environment variable, then the conf file in $HOME/.progrc
   4. If no $HOME/.progrc, then go to a compiled-in default path for a
      directory/progrc
   5. Lastly looking in /etc/progrc

This sort of behavior is best suited for system programs, which might
have a dedicated user account.

If a program will use multiple configuration files, each one modifying
the configuration state (like CSS files), then:

   1. All of the conf files specified on the command line
      * with the option of the command line specifying these files
        are exclusive of other files
   2. If non-exclusive, then the conf file specified by environment
      variable
   3. If no environment variable, then the conf file found in a
      compiled-in default path for a directory/progrc, with /etc/progrc
      last
   4. The user's personal $HOME/.progrc
   5. *Additional* configuration commands specified by environment
      variable (as in commands in variable, rather than filenames)
   6. *Additional* configuration commands specified on the command line
   7. Maybe now look for a current directory ./.progrc

Look at how ssh or vim handles configuration for an example of this.
To get the local directory stuff to work, somewhere else has to enable
the "exrc" option in vim (so-named for compatibility). Whereas ssh will
never use the current directory config without it being explicitly
included, for security reasons.

For testing, always use an exclusive config file on the command line.
That's how you can, as a regular user, run your own configuration of the
system web daemon or your own high-port sshd.

Elijah
------
/usr/bin/sshd -D -f /my/sshd_config

--- SoupGate-Win32 v1.05