Opened 9 years ago

Last modified 8 years ago

#225 new enhancement

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

Reported by: ydario 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 ydario 9 years ago.
Read env from USER_INI
env_ini_2.patch (6.2 KB) - added by ydario 9 years ago.
macro expansion and beginlibpath/endlibpath support.

Download all attachments as: .zip

Change History (6)

Changed 9 years ago by ydario

Read env from USER_INI

comment:1 Changed 9 years ago by ydario

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 9 years ago by ydario

macro expansion and beginlibpath/endlibpath support.

comment:2 Changed 9 years ago by ydario

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

comment:3 Changed 8 years ago by bird

  • Milestone changed from libc-0.6.4 to libc-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 8 years ago by ydario

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.