On Wed, 22 Nov 2017 20:06:54 +0000, Eli the Bearded wrote:

> 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:
>
I've never seen that.  I can't imagine why it would be needed either, let
alone why it should be hidden except from 'ls -a'. However, I can see the
point of making programs search first for ~/.config or .config rather
than for config or ./config, simply because it doesn't clutter a
directory with configuration files. I wouldn't do that, though, because I
like to see and often need to modify a user-specific configuration file.

>    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".
>
I do that - using ~/bin, I mean, but usually just for scripts, but I've
never needed (yet) to have one collection of programs that pre-empt the
default pathlist and another set that are overridden by it.

Is the .local/bin thing something similar?
>
As I say, I've never seen it before, but then Ubuntu do go off along
their own, rather different, track sometimes. I like what I've seen of
Mint/Cinnamon but have never liked the Unify, Gnome 3 and KDE desktops.

I've used the Redhat distro since RH 6.4 and now use Fedora/XFCE on my
X-64 systems. If I was going to move on it would be to Debian Stable
rather than any of the forks, but since I think apt isn't a patch on dnf
for general ease of use, especially now Fedora has the ability to  move
to the next distro version without a clean install or burning a DVD,   -
IMO the package manager is a good enough reason to stay with Fedora.

>> 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.
>
Back in the day, when I was using Win95 alongside Microware's OS/9 and
Linux I got my nose rubbed in that.

Actually, there's an obvious clue - the fact that the configuration file
(s) for Windows apps are almost always in the same directory as the
executable that uses them while UNIX/Linux/OS/9 put them in /etc

This points directly to Windows being designed for a single user because
it puts the kybosh on different users being able to set different
configuration preferences.  OTOH UNIX and its clones have always been
multi-user systems and so have always required a more flexible, per-user
oriented way of handling application configuration.

> I'm not in favor of things searching for configuration in the *current*
> directory by default.
>
Thats why I suggested the search path should be ".:/usr/local/etc:/etc"
Because the default can be put in /etc or /usr/local/etc - sysadmin's
choice (put it in /etc if the program is in /bin or /usr/bin and in /usr/
local/etc if the program is in /usr/local/bin) while making a user-
specific configuration is as simple as copying the default configuration
to '.' and editing it there.

Actually, I also go one step further by almost always implementing  a '-
c=/path/to/config.file' command line option if the program has a
configuration file. That works well regardless of whether the program is
written in C,Java,Python,...

> 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.
>
Yes, that also looks like a good solution, though a little harder to
implement, since mine is very simple:

   fn = ""
   IF -c=file option exists
      fn = file
   ELSE
      FOR dir IN ".:/usr/local/:/etc"
         IF dir/file EXISTS
            fn = dir/file

   IF file == ""
      SET-ERROR No file specified
      STOP
   ELSE
      OPEN fn
         ON-SUCCESS parse configuration
         RUN application
      ELSE
         SET-ERROR File not found

> 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.
>
I've usually seen this done either by making the program read all the
files in a directory and giving them a numeric prefix if their order is
important or by referencing a single file that has INCLUDE or
INCLUDE_DIR statements, but so fat I haven'r needed anthing so complex.

Actually, there was one case where the very complex configuration
included a data dictionary (the project requirement said that we had to
be able to accept arbitrary changes in the input data format that we were
parsing, converting to a common data structure and and storing in a data
warehouse), but here I cheated by making the configuration parser into a
separate program that validated stored the configuration in a few tables
in the data warehouse. The various programs in the data handling chain
read their configuration from the database.

> 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.
>
Indeed - hence my use of the -c-config command-line option.

It looks like we're in total agreement on this one!


--
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

--- SoupGate-Win32 v1.05