Opened 10 years ago

Last modified 9 years ago

#225 new enhancement

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

Reported by: Yuri Dario Owned by: bird
Priority: normal Milestone: libc-0.7
Component: libc-backend Version: 0.6.2
Severity: normal Keywords:


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.

Attachments (2)

env_ini.patch (3.4 KB) - added by Yuri Dario 10 years ago.
Read env from USER_INI
env_ini_2.patch (6.2 KB) - added by Yuri Dario 10 years ago.
macro expansion and beginlibpath/endlibpath support.

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by Yuri Dario

Attachment: env_ini.patch added

Read env from USER_INI

comment:1 Changed 10 years ago by Yuri Dario

The attached patch implements the feature.

USER_INI is scanned for appkeys in the following order:


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.

Changed 10 years ago by Yuri Dario

Attachment: env_ini_2.patch added

macro expansion and beginlibpath/endlibpath support.

comment:2 Changed 10 years ago by Yuri Dario

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

comment:3 Changed 9 years ago by bird

Milestone: libc-0.6.4libc-0.7

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.

comment:4 Changed 9 years ago by 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 ;-)

Note: See TracTickets for help on using tickets.