Sorting environment

Ken Estes
Fri Apr 11 06:27:00 GMT 1997

<J Q B> wrote: 

>> This parenthetical comment about what these systems "use" is not
>> part of the win32 specification.  If there really is Windows NT and
>> Windows 95 software that depends upon sorting, then that is a bug.
>> Not that that has any bearing on the real world, where practical
>> software must accommodate MS's bugs.

The parenthetical comment is quite important. (remember I posted this
bug several months ago). The problem is the way getenv(), _putenv()
handles unsorted environments.  This will give unexpected results if
there is no sorting performed.

When I used _putenv() to modify an unsorted list of env variables the
same variable remained in the environmental array in different places
with different values.  This caused strange problems where Perl
inherits a different environment then C programs spawned from the same
application.  This is because Perl loads the env array into a hash
table manually.  So Perl will remember the LAST environmental setting
of the variable while getenv() returns the FIRST setting of the

This is not a question of user coding style or real world compromises.

1) Applications must be able to use OS functions when desired.

2) Duplicate environmental settings should not occur as a result of
   using OS functions

 To ensure that these simple conditions are met the environment must
be sorted or then environment will enter an inconsistent state as a
result of OS interfaces.  This means that the quotation from the
manual is correct:

>   To do so, the application must explicitly create the =X environment
>   variable strings, get them into alphabetical order (because
>   Windows NT and Windows 95 use a sorted environment), and then put
>   them into the environment block specified by

The application MUST get them into alphabetical order.

Ken Estes

For help on using this list (especially unsubscribing), send a message to
"" with one line of text: "help".

More information about the Cygwin mailing list