From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 17-APR-1991 01:20:12.46 To: ARISIA::EVERHART CC: Subj: Re: need help with VAXC getenv() From: RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2 To: Everhart@Arisia@MRGATE Received: by crdgw1.ge.com (5.57/GE 1.97) id AA02807; Wed, 17 Apr 91 01:13:22 EDT Received: From EQL.CALTECH.EDU by CRVAX.SRI.COM with TCP; Tue, 16 APR 91 19:11:23 PST Date: Tue, 16 Apr 91 19:11:13 PDT From: rankin@EQL.Caltech.Edu (Pat Rankin) Message-Id: <910416190657.21605123@EQL.Caltech.Edu> Subject: Re: need help with VAXC getenv() To: info-vax@sri.com >[...] Is there a way to redefine PATH, and get the proper PATH definition? > > The short answer is NO, The answer is "yes." I showed how to do that a couple of weeks ago. Just update the environ[] array yourself, and getenv() won't know the difference. The only thing special about PATH, HOME, USER, and TERM here is that they're set at program startup and getenv() normally finds them when it scans that array. If you remove them from the array, it will do logical name translation and/or symbol lookup dynamically. This is all that's needed: #include /* put this somewhere in run-time code executed prior to 'getenv()' */ environ = 0; /*[use ``(char **)0'' if it makes you feel better]*/ Note that this will suppress all four of the pre-defined values. You'll _need_ a logical name or symbol for PATH, or else you can easily derive the default value using ``getcwd()''. Alternatively, you can use something like char *foo, **save_environ; save_environ = environ; environ = 0; /* suppress access to pre-defined values */ foo = getenv("PATH"); environ = save_environ; /* restore original data */ if ( !foo ) foo = getenv("PATH"); > there isn't a way to define the logical > name PATH or DCL symbol PATH and have getenv("PATH") return the > correct string due to a bug in VAX C's main routine (c$$main) > which initializes the environment array (at least in > VAX C Version 3.1-051). The version of VAX C has nothing to do with it. The code in question is in VAXCRTL, which is part of VMS. Have you SPR'd this bug? It seems to still be present in VMS V5.4-2. Pat Rankin, rankin@eql.caltech.edu