|Mailing List email@example.com Archived Message #36||back to list|
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?
mentioned in the past it doesn't make sense to goinclude
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.
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.
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.
Mail to ListMaster