Mailing List Archived Message #34

From: "Gregg Young" <> Full Headers
Undecoded message
Subject: Re: [eFTE-dev] Report: relative 'includes' in config (was Re: [eFTE-dev] efte-dev list vs. trac)
Date: Mon, 25 Dec 2017 12:49:26 -0700 (MST)
To: "eFTE Developers Mailing List" <>

Hi Alfred
>>I could make the ../ work if you think it is important. I
>>think it is cleaner without at least for the case where
>>original config files are used this way. You could put
>>config somewhere other than the config directory and
>>would work.
>I think it is important to keep backwards compatibility
>wherever the original logic wasn't faulty -- and I don't
>think the ability to read files from .. qualifies as that. I
>used it to minimize my changes to the original config.

I am not clear what you mean here do you want .. to
work or not?

>Anyway, I plan to revamp the config loading stuff. As I
>mentioned in the past it doesn't make sense to go
>through 20+ different directories to look for every
>-- unless you can defend a solid use case,

This ship has sailed. They all need to stay. This came
from eFTE. We need to consider that individuals could
be sharing a configuration with either Linux or Windows
using eFTE there and eFTE2 on OS2. There is also the
chance a regular *NIX user installed eFTE2 in a more
*NIX way. They could be using any of the hard coded
paths for these configurations.

It doesn't search them all just until it finds the file. We
just need the most likely first.

I think it is
>much better to look in a few places to locate the initial
>system.fte or whatever, then try to load everything else
>relative to it, and relative to config dir as well -- just to
>avoid breaking potentially existing eFTE configs using
>the old scheme, but that is as much as I can
>contemplate right now.

The order should be "relative" then EFTEDIR followed by
config then the rest. This will achieve what you want
without potentially breaking it for others.

>That's the last thing I need to fix before I can switch
>from ol' FTE to eFTE2, though, so we still have some
>time to discuss it.

Not much to fix. If you want the ../ to work it is a little bit
of string handling. I do think I should fix it to tolerate ./
which is easy.

Not sure what to do with a leading / since it would mean
relative to the root in a command processor but isn't
likely to mean that in this context. It more likely is
intended to be a subdirectory of the current directory.
Could search both I guess. Thanks

Merry Christmas


Subscribe: Feed, Digest, Index.
Mail to ListMaster