Mailing List Archived Message #36

From: "Alfredo Fernández Díaz" <> Full Headers
Undecoded message
Subject: Re: [eFTE-dev] Report: relative 'includes' in config (was Re: [eFTE-dev] efte-dev list vs. trac)
Date: Tue, 26 Dec 2017 01:50:36 +0100
To: eFTE Developers Mailing List <>

Hi again,

Gregg Young wrote:
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?

Sorry, I meant 'does not qualify as faulty logic to me', i.e. I want it to work -- I use it.

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.

That's an interesting case. However, the current list of directories to go through is different depending on the target OS. Also, directories shared across systems are likely to have different access paths under each OS (drive letters, mount points, etc.), etc, and there are many lazy assumptions like 'C:', or 'Program Files [(x86)]' -- I never had that even in my Windows systems. Proper environment checks should work so much better.

That definitely needs some work.

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

Sorry, I don't understand what you mean there.

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.

I meant if %EFTEDIR%/dir/a.fte includes "b.fte", cfte should look for %EFTEDIR%/dir/b.fte, then the unexpected %EFTEDIR%/b.fte in case anyone relied on old efte code to handle that for them.

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.

Exactly, chop off the two first characters and process like before. I don't know what kind of Unix heads would insist in using that, but if it makes you happy...

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.

Always a problem on Win/OS/2. I usually interpret that as 'root of current drive', but I tend to avoid those whenever I can.

Merry Christmas,

Subscribe: Feed, Digest, Index.
Mail to ListMaster