Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / May 2006

Tip: Looking for answers? Try searching our database.

Odd behavior of getenv and putenv

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Yogi Watcher - 02 May 2006 23:29 GMT
Hi,

Recently I have observed some odd behavior of getenv and putenv function. I
am developing some code that integrates with several other libraries. This
program is not using MFC. It is plain C and C++ code.

Some login and initialization function from one dll is setting an
environment variable “MANUAL_LOGIN” to value “TRUE”. I tried three different
cases and here is what I found:

Case 1: If I write following code in my function:

       char    *val = getenv (“MANUAL_LOGIN”) ;
       printf (“MANUAL_LOGIN = [%s]\n”, val == NULL ? “” : val) ;
       system (“echo MANUAL_LOGIN = [%MANUAL_LOGIN%]”) ;

   then I get following output on screen:

       MANUAL_LOGIN = []
       MANUAL_LOGIN = [TRUE]

Case 2: If I use same code as in case 1, but define following environment
variable on the command line prior to running the program:
       set MANUAL_LOGIN=SOME_JUNK

   then I get following output on screen:

       MANUAL_LOGIN = [SOME_JUNK]
       MANUAL_LOGIN = [TRUE]

Case 3: Now if I write following code in my function:

       putenv (“MANUAL_LOGIN=SOME_JUNK”) ;
       char    *val = getenv (“MANUAL_LOGIN”) ;
       printf (“MANUAL_LOGIN = [%s]\n”, val == NULL ? “” : val) ;
       system (“echo MANUAL_LOGIN = [%MANUAL_LOGIN%]”) ;

   then I get following output on screen:

       MANUAL_LOGIN = [SOME_JUNK]
       MANUAL_LOGIN = [SOME_JUNK]

So it seems that getenv() and system() look at different environment. Can
somebody please explain me what is happening here? My goal is to get original
value of environment variable. Change it to different value and then do some
processing and reset it back to its original value. Any idea how I can
achieve that?

Here is another odd behavior that I saw, this time with putenv. Following
code does not unset the environment variable, even though there is nothing
after = sign:

   putenv (“MANUAL_LOGIN=”) ;

This may or may not be related to what I have described above.

Any explanations?
Doug Harrison [MVP] - 03 May 2006 04:07 GMT
>Hi,
>
[quoted text clipped - 16 lines]
>        MANUAL_LOGIN = []
>        MANUAL_LOGIN = [TRUE]

This sounds like the modules (EXE, DLL) are using different CRTs and thus
have distinct C-level environments. Sticking to the Windows functions
GetEnvironmentVariable and SetEnvironmentVariable should work for you, or
you could link everyone to the same CRT DLL so they would share CRT state.

>Case 2: If I use same code as in case 1, but define following environment
>variable on the command line prior to running the program:
[quoted text clipped - 4 lines]
>        MANUAL_LOGIN = [SOME_JUNK]
>        MANUAL_LOGIN = [TRUE]

Right, the new process inherits the environment of the process that started
it, so this is expected.

>Case 3: Now if I write following code in my function:
>
[quoted text clipped - 10 lines]
>So it seems that getenv() and system() look at different environment. Can
>somebody please explain me what is happening here?

If DLL X links to a different CRT than DLL Y, they will have separate
C-level environments, heap, errno, etc.

>My goal is to get original
>value of environment variable. Change it to different value and then do some
>processing and reset it back to its original value. Any idea how I can
>achieve that?

Link everyone to the same CRT DLL or use the Windows functions.

>Here is another odd behavior that I saw, this time with putenv. Following
>code does not unset the environment variable, even though there is nothing
[quoted text clipped - 5 lines]
>
>Any explanations?

Depending on where you're doing your getenv, it may well be related.

Signature

Doug Harrison
Visual C++ MVP

Yogi Watcher - 03 May 2006 20:07 GMT
Thanks Doug.

That's exactly what was causing this. Once I fixed this, the issue that I
saw with putenv went away too.

Thanks a lot.

> >Hi,
> >
[quoted text clipped - 70 lines]
>
> Depending on where you're doing your getenv, it may well be related.
Yogi Watcher - 03 May 2006 20:16 GMT
Now I have interesting question. If DLL X links to different CRT than DLL Y,
and If I change some environment variable in a function in DLL Y and then
spawn a process, then which environment will the spawned process get? one
(modified) from DLL Y, or one (original) from DLL X or combination of both
(???).

Thanks

> >Hi,
> >
[quoted text clipped - 70 lines]
>
> Depending on where you're doing your getenv, it may well be related.
Doug Harrison [MVP] - 04 May 2006 05:21 GMT
>Now I have interesting question. If DLL X links to different CRT than DLL Y,
>and If I change some environment variable in a function in DLL Y and then
>spawn a process, then which environment will the spawned process get? one
>(modified) from DLL Y, or one (original) from DLL X or combination of both
>(???).

If you start the process using a CRT function, it will get the  environment
from the CRT instance whose function you invoked. So if you invoke the
program from DLL X, it will get the environment from the CRT DLL X is
using. Same for DLL Y or any other module. If you want to use the
Windows-level environment, use CreateProcess directly. Note that putenv
does set both the CRT and Windows environments.

Signature

Doug Harrison
Visual C++ MVP


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.