getenv() access (read-only) variables also from .INI files

[Yuri Dario]

The main problem with environment variables is that they need to be saved to config.sys to get proper setup, and this requires a reboot under os/2.

It will be nice if getenv() will try to read variable value also from a specialized INI file, so we can easily change values on the fly using regedit (or similar tools).

The INI file should be located into hardcoded location (e.g. %ETC%) and maybe into user home (overrides global ini).

INI should save data in the format: key=variable_name, value=type,value Data can be stored also on a per-program setup, using key=program_name+variable_name; program specific setup has priority over global define. value will store a string, it will be nice to add some macro expansion to allow extending config.sys variables.

Writing to INI values using setenv()/putenv() is not allowed.

INI values should be added at program enviroment pool at startup, so getenv() and friends will access them without changes to code. Also childs will inherit automatically the new environment.

[Yuri Dario]

Read env from USER_INI

[Yuri Dario]

The attached patch implements the feature.

USER_INI is scanned for appkeys in the following order:

KLIBC KLIBC_PROGRAMNAME.EXE KLIBC_X:\PATH\PROGRAMNAME.EXE

New entries are overriding previous entries.

Ini keys must be uppercase for both application name and variable. BTW OS/2 is case insensitive for variable names, while setenv() is case-sensitive.

I added code into _init_dll.c, maybe a different place is better suited for this.

Also USER_INI is used instead of custom .ini file: I don't think too many variables will be added, so this should not be a problem for main OS/2 user ini.

[Yuri Dario]

macro expansion and beginlibpath/endlibpath support.

[Yuri Dario]

New patch adds also macro expansion and support for BEGINLIBPATH/ENDLIBPATH system variables. Added also a missing free() call :-)

[bird]

Nice idea but I don't see libc doing this for every application since it isn't very unixy, dosish or windowsy. The beginlibpath/endlibpath bits, could be argued as an RPATH (ELF) feature but I'd rather see LX hacks or EAs for that purpose.

I'm also not so much a fan of .ini files. A programname.klibc-env text file next to the programname.exe would be quicker to check for, easier to install (you unzip it) and just as flexible unless you count all the multi-user OS/2 setups.

[Yuri Dario]

While .ini files are not the most robust file format available, I don't think that moving to files next to programname.exe is good: it will make very hard for users to check for such personalization of environment, and almost impossible for a single program to retrieve all these files and give users a single editor for all of them.

Regardless of file format, this kind of info must be stored in a single position, possibly dependent on username, so we can keep doors open to multiuser solutions.

I'd like to see this as a 0.6.x feature, but I can't vote for myself ;-)