Modifying process environment - OS2

This is a discussion on Modifying process environment - OS2 ; I thought this should be elementary - but I can't find any way to modify the environment of the current process. Win32 has a nice SetEnvironmentVariable API, Unix has setenv(). Does OS/2 have an equivalent? Note that I'm talking about ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 36

Thread: Modifying process environment

  1. Modifying process environment


    I thought this should be elementary - but I can't find any way to
    modify the environment of the current process. Win32 has a nice
    SetEnvironmentVariable API, Unix has setenv(). Does OS/2 have an
    equivalent?

    Note that I'm talking about the OS/2 process environment, not
    the environment maintained by a C runtime library.


    Michal


  2. Re: Modifying process environment

    On Sat, 11 Dec 2004 07:12:15 GMT, Michal Necasek
    wrote:

    > I thought this should be elementary - but I can't find any way to
    > modify the environment of the current process. Win32 has a nice
    > SetEnvironmentVariable API, Unix has setenv(). Does OS/2 have an
    > equivalent?
    >
    > Note that I'm talking about the OS/2 process environment, not
    > the environment maintained by a C runtime library.


    Not that I can see, but....
    The pib_pchenv member of the PIB structure returned by DosGetInfoBlocks()
    is writable.
    From my tests, the memory allocated for the environment is page granular
    and writable, but if you need more you can just allocate it, copy the
    old to the new and then reassign the pointer at pib_pchenv.

    You have to manage the strings in memory yourself whatever.

  3. Re: Modifying process environment

    Michal Necasek wrote:

    > I thought this should be elementary - but I can't find any way to
    > modify the environment of the current process.


    I dont think that such function exist, the mechanism usually
    used is to pass a modified environment to newly started processes.
    Altering the environment by replacing bytes in the original
    environment works. Example is replacing '@' to drive letters
    using a device= driver (running in process #1), that change
    is used for all later processes.

    --
    Veit Kannegieser

  4. Re: Modifying process environment

    EMX has

    int putenv (const char *string)

    which puts a string of the form "var=value" into the
    calling processes's environment.

    Andy Staszko


    Michal Necasek wrote:
    >
    > I thought this should be elementary - but I can't find any way to
    > modify the environment of the current process. Win32 has a nice
    > SetEnvironmentVariable API, Unix has setenv(). Does OS/2 have an
    > equivalent?
    >
    > Note that I'm talking about the OS/2 process environment, not
    > the environment maintained by a C runtime library.
    >
    >
    > Michal
    >


  5. Re: Modifying process environment

    Andy Staszko wrote:

    > EMX has
    >
    > int putenv (const char *string)
    >
    > which puts a string of the form "var=value" into the
    > calling processes's environment.
    >

    What's wrong with me? Do I not speak English? I'll
    quote myself:

    >> Note that I'm talking about the OS/2 process environment, not
    >> the environment maintained by a C runtime library.
    >>


    Unless I missed something really substantial in the EMX source
    code (I don't think so), EMX's setenv()/putenv() DO NOT modify the
    OS environment, just the C runtime copy. I know how to do _that_.


    Michal


  6. Re: Modifying process environment

    Paul Ratcliffe wrote:

    > Not that I can see, but....
    > The pib_pchenv member of the PIB structure returned by DosGetInfoBlocks()
    > is writable.
    >

    I was thinking of that. But I was wondering if there was some, hmm,
    less dangerous sounding way.

    > From my tests, the memory allocated for the environment is page granular
    > and writable, but if you need more you can just allocate it, copy the
    > old to the new and then reassign the pointer at pib_pchenv.
    >

    That works? Interesting. What about the size limitations? What about
    16-bit apps?

    If this method works, I might want to incorporate it into the Open
    Watcom runtime lib.

    > You have to manage the strings in memory yourself whatever.
    >

    Of course...

    The reason why I'm asking is subtle. Normally it's fine for a C runtime
    to maintain a copy of the environment and pass it to child processes. The
    catch is that several OS/2 APIs, notably DosExecPgm and DosQueryAppType,
    use the OS/2 process environment. So if I change, say, PATH with a call
    to setenv() or putenv(), those APIs won't know about it.


    Michal


  7. Re: Modifying process environment

    On Sat, 11 Dec 2004 19:21:50 UTC, Michal Necasek
    wrote:

    > The reason why I'm asking is subtle. Normally it's fine for a C runtime
    > to maintain a copy of the environment and pass it to child processes. The
    > catch is that several OS/2 APIs, notably DosExecPgm and DosQueryAppType,
    > use the OS/2 process environment. So if I change, say, PATH with a call
    > to setenv() or putenv(), those APIs won't know about it.


    Not true.

    There is an process environment. A program inherits its parents
    environment.
    So change the environment and start a child process and it will see
    your environment. Change it again and start another - and it sees the
    changed one while the already running one sees no change. The trick is
    to start another process as child, not independant. Read the
    documentation about DosStartProgram, DosStartSession, WinStartApp.

    Attention: libpath is NOT an environment variable - but
    beginlibpath/endlibpath are.

    You can check it by do as described and use DosQueryAppType or the
    environment pointer you'll get with int main(int argc, char *argv[],
    char *envp);

    --
    Tschau/Bye
    Herbert

    Visit http://www.ecomstation.de the home of german eComStation
    eComStation 1.2 Deutsch ist da!

  8. Re: Modifying process environment

    Herbert Rosenau wrote:

    >> The reason why I'm asking is subtle. Normally it's fine for a C runtime
    >>to maintain a copy of the environment and pass it to child processes. The
    >>catch is that several OS/2 APIs, notably DosExecPgm and DosQueryAppType,
    >>use the OS/2 process environment. So if I change, say, PATH with a call
    >>to setenv() or putenv(), those APIs won't know about it.

    >
    > Not true.
    >

    You're wrong.

    > There is an process environment. A program inherits its parents
    > environment.
    >

    I don't see how that is relevant to the discussion at hand.

    > So change the environment and start a child process and it will see
    > your environment.
    >

    And what is "your environment" in the above sentence? The one
    maintained by the C runtime or the one maintained by the OS? Anyway
    I'm not interested in starting child processes here.

    Let me rephrase the question so that there is no ambiguity: How do
    I modify the environment of the current process without using any
    C library functions?

    > Attention: libpath is NOT an environment variable - but
    > beginlibpath/endlibpath are.
    >

    Nonsense. You're telling me to read the documentation while you
    yourself obviously haven't done that. I'll quote CPREF for you:
    "Note: The extended LIBPATHs are not true environment variables,
    and do not appear when querying the environment." The fact that CMD.EXE
    does its best to pretend that BEGINLIBPATH is an env var does
    not make it an env var.


    Michal


  9. Re: Modifying process environment

    On Sat, 11 Dec 2004 19:21:50 GMT, Michal Necasek
    wrote:

    > I was thinking of that. But I was wondering if there was some, hmm,
    > less dangerous sounding way.


    Not that I know of.

    >> From my tests, the memory allocated for the environment is page granular
    >> and writable, but if you need more you can just allocate it, copy the
    >> old to the new and then reassign the pointer at pib_pchenv.
    >>

    > That works? Interesting. What about the size limitations?


    What size limitations? I can't see there are any.

    > What about 16-bit apps?


    No idea. Didn't try one. I suspect the same thing applies though.

    > The reason why I'm asking is subtle. Normally it's fine for a C runtime
    > to maintain a copy of the environment and pass it to child processes. The
    > catch is that several OS/2 APIs, notably DosExecPgm and DosQueryAppType,
    > use the OS/2 process environment. So if I change, say, PATH with a call
    > to setenv() or putenv(), those APIs won't know about it.


    True.

  10. Re: Modifying process environment

    On Sun, 12 Dec 2004 00:31:33 +0000 (UTC), Herbert Rosenau
    wrote:

    >> The reason why I'm asking is subtle. Normally it's fine for a C runtime
    >> to maintain a copy of the environment and pass it to child processes. The
    >> catch is that several OS/2 APIs, notably DosExecPgm and DosQueryAppType,
    >> use the OS/2 process environment. So if I change, say, PATH with a call
    >> to setenv() or putenv(), those APIs won't know about it.

    >
    > Not true.


    Yes it is true.

    > There is an process environment. A program inherits its parents
    > environment.


    True, but you are talking about the C runtime library's environment.
    This is created from the process's environment. Changes caused by
    putenv()/setenv() are not copied back.

    > So change the environment and start a child process and it will see
    > your environment. Change it again and start another - and it sees the
    > changed one while the already running one sees no change. The trick is
    > to start another process as child, not independant. Read the
    > documentation about DosStartProgram, DosStartSession, WinStartApp.
    >
    > You can check it by do as described and use DosQueryAppType or the
    > environment pointer you'll get with int main(int argc, char *argv[],
    > char *envp);


    Did you not read the question or do you just not understand?
    What has envp got to do with it when you are using Dos* API calls?
    The latter knows nothing about the former.

    Are you sure your name isn't Hartzell?

  11. Re: Modifying process environment

    Paul Ratcliffe wrote:

    >> That works? Interesting. What about the size limitations?

    >
    > What size limitations? I can't see there are any.
    >

    Bad things start happening if the size of the environment gets
    close to 32K. I don't recall the exact details but I think that
    if the total size of environment strings is "too big", DosExecPgm
    starts failing. I seem to remember that "too big" was just under
    32K.

    >>What about 16-bit apps?

    >
    > No idea. Didn't try one. I suspect the same thing applies though.
    >

    But 16-bit apps have no PIB and the env strings are stored in
    a special environment segment... which I don't think can be
    reallocated.

    I just thought of a problem with changing the OS enviroment,
    although I'm not sure if it's a real problem or not: If some code
    kept a pointer to the strings in the OS environment, reallocating
    will invalidate that pointer.


    Michal


  12. Re: Modifying process environment

    On Sun, 12 Dec 2004 01:03:29 UTC, Michal Necasek
    wrote:

    > Herbert Rosenau wrote:
    >
    > >> The reason why I'm asking is subtle. Normally it's fine for a C runtime
    > >>to maintain a copy of the environment and pass it to child processes. The
    > >>catch is that several OS/2 APIs, notably DosExecPgm and DosQueryAppType,
    > >>use the OS/2 process environment. So if I change, say, PATH with a call
    > >>to setenv() or putenv(), those APIs won't know about it.

    > >
    > > Not true.
    > >

    > You're wrong.


    Prove it. When you have 300 applications running there are 300
    environments. They may differ from the one created at startup - or
    not.

    > > There is an process environment. A program inherits its parents
    > > environment.
    > >

    > I don't see how that is relevant to the discussion at hand.
    >
    > > So change the environment and start a child process and it will see
    > > your environment.
    > >

    > And what is "your environment" in the above sentence? The one
    > maintained by the C runtime or the one maintained by the OS? Anyway
    > I'm not interested in starting child processes here.


    The C runtime does nothing more than to give you the same environment
    that you gets with DosScanEnv()

    Or in C:

    #include
    char *getenv(const char *varname);
    int putenv(char *envstring);

    fom IBM Developer Toolkit 4.51 C library.

    > Let me rephrase the question so that there is no ambiguity: How do
    > I modify the environment of the current process without using any
    > C library functions?


    I would use in C simply DosSetEnv();
    Yes, I know in tooklit 4.0 it was not documented - but in 4.5x it is
    again.

    > > Attention: libpath is NOT an environment variable - but
    > > beginlibpath/endlibpath are.
    > >

    > Nonsense. You're telling me to read the documentation while you
    > yourself obviously haven't done that. I'll quote CPREF for you:
    > "Note: The extended LIBPATHs are not true environment variables,
    > and do not appear when querying the environment." The fact that CMD.EXE
    > does its best to pretend that BEGINLIBPATH is an env var does
    > not make it an env var.
    >
    >
    > Michal
    >



    --
    Tschau/Bye
    Herbert

    Visit http://www.ecomstation.de the home of german eComStation
    eComStation 1.2 Deutsch ist da!

  13. Re: Modifying process environment

    Herbert Rosenau wrote:

    > Prove it.
    >

    See below.

    > When you have 300 applications running there are 300
    > environments. They may differ from the one created at startup - or
    > not.
    >

    And? This has nothing to do with what I was asking about.

    > The C runtime does nothing more than to give you the same environment
    > that you gets with DosScanEnv()
    >

    Are you being deliberately obtuse or are you really so ignorant?
    No, the C runtime most certainly DOES do a whole lot more than
    DosScanEnv. In fact, it typically never calls DosScanEnv at all.
    Try this:

    ---------------------------------------------------
    #include
    #include

    #define INCL_DOSMISC
    #include

    int main( void )
    {
    char *s;
    char *var = "USER_INI";

    putenv( "USER_INI=junk" );
    DosScanEnv( var, &s );
    printf( "DosScanEnv says: %s=%s\n", var, s );
    s = getenv( var );
    printf( "getenv() says: %s=%s\n", var, s );
    return( 0 );
    }
    ---------------------------------------------------

    Every compiler I tried (Watcom, VAC++ 3.08, gcc 3.2, Borland)
    prints this:

    DosScanEnv says: USER_INI=D:\OS2\OS2.INI
    getenv() says: USER_INI=junk

    Can you please explain to me how that is possible if, as you claim,
    "The C runtime does nothing more than to give you the same environment
    that you gets with DosScanEnv()"?

    > I would use in C simply DosSetEnv();
    > Yes, I know in tooklit 4.0 it was not documented - but in 4.5x it is
    > again.
    >

    Where? I can't find it. It's not in the Debugging Handbook, in the
    Toolkit headers or on Google. Please give me exact details - function
    prototype and ordinal number. I really hope you didn't just make that
    API up.


    Michal


  14. Re: Modifying process environment

    Paul Ratcliffe wrote:
    > On Sat, 11 Dec 2004 19:21:50 GMT, Michal Necasek
    > wrote:
    >>>From my tests, the memory allocated for the environment is page granular
    >>>and writable, but if you need more you can just allocate it, copy the
    >>>old to the new and then reassign the pointer at pib_pchenv.
    >>>

    >>
    >> That works? Interesting. What about the size limitations?

    >
    >
    > What size limitations? I can't see there are any.
    >


    64K maybe?


  15. Re: Modifying process environment

    Michal Necasek wrote:
    > I just thought of a problem with changing the OS enviroment,
    > although I'm not sure if it's a real problem or not: If some code
    > kept a pointer to the strings in the OS environment, reallocating
    > will invalidate that pointer.


    If something *can* be done, you can be sure someone is doing it.


  16. Re: Modifying process environment

    On Sun, 12 Dec 2004 11:35:33 UTC, Michal Necasek
    wrote:

    > Herbert Rosenau wrote:
    >
    > > Prove it.
    > >

    > See below.
    >
    > > When you have 300 applications running there are 300
    > > environments. They may differ from the one created at startup - or
    > > not.
    > >

    > And? This has nothing to do with what I was asking about.
    >
    > > The C runtime does nothing more than to give you the same environment
    > > that you gets with DosScanEnv()
    > >

    > Are you being deliberately obtuse or are you really so ignorant?
    > No, the C runtime most certainly DOES do a whole lot more than
    > DosScanEnv. In fact, it typically never calls DosScanEnv at all.
    > Try this:
    >
    > ---------------------------------------------------
    > #include
    > #include
    >
    > #define INCL_DOSMISC
    > #include
    >
    > int main( void )
    > {
    > char *s;
    > char *var = "USER_INI";
    >
    > putenv( "USER_INI=junk" );
    > DosScanEnv( var, &s );
    > printf( "DosScanEnv says: %s=%s\n", var, s );
    > s = getenv( var );
    > printf( "getenv() says: %s=%s\n", var, s );
    > return( 0 );
    > }
    > ---------------------------------------------------
    >
    > Every compiler I tried (Watcom, VAC++ 3.08, gcc 3.2, Borland)
    > prints this:
    >
    > DosScanEnv says: USER_INI=D:\OS2\OS2.INI
    > getenv() says: USER_INI=junk
    >
    > Can you please explain to me how that is possible if, as you claim,
    > "The C runtime does nothing more than to give you the same environment
    > that you gets with DosScanEnv()"?
    >
    > > I would use in C simply DosSetEnv();
    > > Yes, I know in tooklit 4.0 it was not documented - but in 4.5x it is
    > > again.
    > >

    > Where? I can't find it. It's not in the Debugging Handbook, in the
    > Toolkit headers or on Google. Please give me exact details - function
    > prototype and ordinal number. I really hope you didn't just make that
    > API up.



    IBM Toolkit 4.51:

    Outgoing from you have it installed:
    Programs -> Developement ->
    IBM Developers Toolkit version 4.5 ->
    IBM Tookit Information -> C Library Reference

    Open it using view or newview, search: putenv

    --------------------
    putenv - modify ennvironment variables

    [lots of text like header declared in, usage, sample...]

    Related Information


    execl - _execvpe
    getenv
    _spawnl - _spawnvpe
    system
    "envp Parameter to main" in the VisualAge C++ Programming Guide
    ---------------------------

    \os2tk45\h\libc\stdlib.h

    lines 214, 215, 234, 244, 254


    And the sample shows clearly that putenv DOES change the environment
    of the process:

    ude
    #include

    int main(void)
    {
    char *pathvar;

    if (-1 == putenv("PATH=a:\\bin;b:\\andy")) {
    printf("putenv failed - out of memory\n");
    return EXIT_FAILURE;
    }

    /* getting and printing the current environment path
    */

    pathvar = getenv("PATH");
    printf("The current path is: %s\n", pathvar);
    return 0;


    /************************************************** *******************
    *******
    The output should be:

    The current path is: a:\bin;b:\andy

    ************************************************** ********************
    ******/
    }



    --
    Tschau/Bye
    Herbert

    Visit http://www.ecomstation.de the home of german eComStation
    eComStation 1.2 Deutsch ist da!

  17. Re: Modifying process environment

    Sorry, I thought there may have been some hidden piece of magic
    being used: Watcom and the IBM toolkits do the same.

    However, I too speak English (the English kind - there is no other!)

    and...

    It seems you're well and truly stuffed!

    Andy Staszko

    Michal Necasek wrote:
    > Andy Staszko wrote:
    >
    >> EMX has
    >>
    >> int putenv (const char *string)
    >>
    >> which puts a string of the form "var=value" into the
    >> calling processes's environment.
    >>

    > What's wrong with me? Do I not speak English? I'll
    > quote myself:
    >
    >>> Note that I'm talking about the OS/2 process environment, not
    >>> the environment maintained by a C runtime library.
    >>>

    >
    > Unless I missed something really substantial in the EMX source
    > code (I don't think so), EMX's setenv()/putenv() DO NOT modify the
    > OS environment, just the C runtime copy. I know how to do _that_.
    >
    >
    > Michal
    >


  18. Re: Modifying process environment

    On Sun, 12 Dec 2004 14:10:22 UTC, "Herbert Rosenau"
    wrote:

    > Open it using view or newview, search: putenv
    >
    > --------------------
    > putenv - modify ennvironment variables
    >
    > [lots of text like header declared in, usage, sample...]
    >
    > Related Information
    > execl - _execvpe
    > getenv
    > _spawnl - _spawnvpe
    > system
    > "envp Parameter to main" in the VisualAge C++ Programming Guide


    I cannot speak for VisualAge, but looking at the RTL source
    for Borland C++, I see that putenv() works on a copy of the
    original environment strings. The code for updating the real
    process environment is inside an #ifdef __WIN32__ block.
    For OS/2, they just do nothing. This means, that any change
    done by putenv() will only be reflected by the CRTL functions
    - like the mentioned ones -. DosScanEnv() will *NOT* see these
    modifications. But this is, what Michal wants to achive !

    Maybe Borland is doing this due to the lack of a proper API.
    But OTOH, this API may be nonexistent by design. Since
    DosScanEnv returns a pointer to the string (instead of copying
    it), a modification of the original environment would cause
    unpredictable results.


    --
    Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
    http://www.s-t.de
    Please remove all characters left of the "R" in my email address


  19. Re: Modifying process environment

    On Sat, 11 Dec 2004 07:12:15 UTC, Michal Necasek wrote:
    >
    > I thought this should be elementary - but I can't find any way to
    > modify the environment of the current process. Win32 has a nice
    > SetEnvironmentVariable API, Unix has setenv(). Does OS/2 have an
    > equivalent?


    Small world :-) Yesterday I was attempting to do exactly this.
    I gave up. In a nutshell: 32-bit code, no problem; 16-bit code,
    no joy.

    I'm updating my Run! util and wanted to modify its environment so
    I could it pass it as-is to the program it starts without having
    to make a separate copy. Adding & removing strings was no problem
    as long as I didn't cross a page boundary. However, when I called
    DosStartSession(), I kept getting an access violation in 16-bit code.

    Eventually I realized it was an access limit problem: using a 16-bit
    selector, the segment was exactly as long as the original environment
    + f/q exename + commandline arguments. I tried calling DosSizeSeg()
    to get its size and DosReallocSeg() to change it, but all attempts
    failed. I don't recall the rc, but yes, I was using suitably-thunked
    pointers/selectors.

    Why I encountered this problem is hard to understand. If you've ever
    looked at cmd.exe's environment after entering a few SET statements,
    you'll see that they're tacked on at the end of its existing strings.
    In doing so, it clobbers the f/q exename and the commandline parms
    that follow the environment, but with no ill effect AFAICT. If the
    prototypical 16-bit app can modify its environment, why can't I?


    --
    == == almost usable email address: rws AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | New - Remote Workplace Server v0.60
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws060.zip
    __________________________________________________ _________________

  20. Re: Modifying process environment

    Herbert Rosenau wrote:

    >>>I would use in C simply DosSetEnv();


    > Open it using view or newview, search: putenv
    >

    You said DosSetEnv earlier. Where is it?

    > And the sample shows clearly that putenv DOES change the environment
    > of the process:
    >

    Thanks for making it absolutely clear that you don't know what
    you're talking about. From now on I know I can safely ignore you.


    Michal



+ Reply to Thread
Page 1 of 2 1 2 LastLast