(j3.2006) Fwd: the F2003 get_environment_variable intrinsic routine

[Van Snyder]

Bill Long wrote:
> You don't really "add" an environment variable - you just set it.  The 
> current get_environment_variable is basically a clone of pxfgetenv.  
> There is a companion pxfsetenv which we could similarly clone.  There 
> might be hidden worms in this can, but on the surface it does not seem 
> like a big deal, at least technically.
>   

I don't see a reason for this to be intrinsic.  If it's really desirable 
to standardize libc and posix, those interested in it should develop a 
module that uses C interoperability to access these facilities, and try 
to get it standardized as a separate part.

Van

> Cheers,
> Bill
>
>
>
> Dan Nagle wrote:
>   
>> Hi,
>>
>> FYI Only
>>
>> I neither endorse nor condemn the attached proposal.
>>
>> I am unacquainted with the original sender.
>>
>> Begin forwarded message:
>>
>>     
>>> *From: *"Brocci, R. A." <brocci at kapl.gov <mailto:brocci at kapl.gov>>
>>> *Date: *May 19, 2009 2:47:45 PM EDT
>>> *To: *danlnagle at mac.com <mailto:danlnagle at mac.com>
>>> *Cc: *"Brocci, R. A." <brocci at kapl.gov <mailto:brocci at kapl.gov>>
>>> *Subject: **the F2003 get_environment_variable intrinsic routine*
>>>
>>> Dan,
>>>  
>>> Below you will find a Fortran enhancement suggestion first made last 
>>> week to Walt Brainerd, who as you can see, told me he is no longer a 
>>> member of the standards committee, and suggested that I contact you.
>>>  
>>> My suggestion is that the X_environment_variable routines be added to 
>>> the standard, where X is at least add and perhaps clear or set as well
>>>  
>>> I envision the X = add routine as having the same arguments as the 
>>> current X = get routine; namely
>>>
>>>     * arg1 is the case-sensitive intent(in) environmental parameter
>>>       character string; e.g., 'danNagle' 
>>>     * arg2 is the case-sensitive intent(in) environmental parameter
>>>       value character string; e.g., 'is the Fortran J3 committee chair' 
>>>     * arg3 is the intent(in) integer string length associated with
>>>       arg2; the default is the length of arg2
>>>     * arg4 is the intent(out) integer status return value; with -1,
>>>       0, and 1 --> error, okay, and have over-ridden an existing
>>>       value respectively (I can see a character status return --
>>>       think iomsg -- here, with error, blank or okay, and the
>>>       over-ridden entry as the return strings respectively.)
>>>     * arg5 is the intent(in) logical trailing blanks flag associated
>>>       with arg2; the default is .true. --> don't store trailing
>>>       blanks in arg2 (I'm not sure I see a reason for storing leading
>>>       blanks either, but ... And, I don't see a situation where I
>>>       would not be placing trim(adjustl(...)) in the arg2 position.)
>>>
>>> As you can see below in my comments to Walt, I personally have never 
>>> seen a need for the X = clear routine, but others I've talked to over 
>>> the years have indicated otherwise. At this time, I'd envision X = 
>>> clear having just the status (arg4 above) argument.
>>>  
>>> If you would prefer that emails such as this go to someone else on 
>>> the Standards Committee, please let me know by providing their 
>>> contact info.
>>>  
>>>  
>>> Thanks for your time.
>>>  
>>>  
>>>  
>>> Tony Brocci   18 May 2009
>>> KAPL
>>> PO Box 1072,  Mail Stop 122
>>> Schenectady, NY  12301
>>> 518-395-6682
>>> brocci at kapl.gov <mailto:brocci at kapl.gov>
>>>  
>>> Walt's response from 14 May 2009 follows.
>>>  
>>> Sounds like a worthwhile idea, but I'm not on the stds comm. any
>>> longer, so can't do anything for you.
>>>  
>>> The chair of J3 is Dan Nagle: danlnagle at mac.dom 
>>> <mailto:danlnagle at mac.dom>. He might tell
>>> you how to best submit an idea. Just one thought: the more
>>> specific the proposal, the better. Even if the committee completely
>>> changes the specifics, it is good to start with something concrete.
>>>  
>>> I always enjoy hearing from you :-).
>>>
>>> On Thu, May 14, 2009 at 5:31 AM, Brocci, R. A. <brocci at kapl.gov 
>>> <mailto:brocci at kapl.gov>> wrote:
>>>
>>>     Walt,
>>>      
>>>     I see where the 2003 standard introduced the
>>>     get_environment_variable routine as the official replacement for
>>>     the long-standing getenv routine -- which I started using a long
>>>     time ago.
>>>      
>>>     For completeness, I think there should also be the
>>>     X_environment_variable companion routines, where X is at least
>>>     add to add 1 or more variables to the environment, and
>>>     perhaps clear to over-write the existing environment.
>>>      
>>>     Note: The long-standing putenv routine was supposed to do the
>>>     add, but the last time I ran my test cases, I found it too flaky
>>>     to be used in "production" code. And obviously, having X = clear
>>>     isn't of much value without having X = add as well.
>>>      
>>>     I've included X = clear simply because it has come up in
>>>     previous "internal" discussions on this topic. I personally can't
>>>     think of a past situation where I would have done a clear_... and
>>>     then an add_... to get the "minimal" environment of interest to
>>>     my executable.
>>>      
>>>     If you would prefer that emails such as this go to someone else
>>>     on the Standards Committee, please let me know by providing their
>>>     contact info. As always, it is a pleasure to "talk" to you.
>>>      
>>>     Thanks for your time.
>>>      
>>>      
>>>      
>>>     Tony Brocci   14 May 2009
>>>     KAPL
>>>     PO Box 1072,  Mail Stop 122
>>>     Schenectady, NY  12301
>>>     518-395-6682
>>>     brocci at kapl.gov <mailto:brocci at kapl.gov>
>>>      
>>>
>>>
>>>
>>>
>>> -- 
>>> Walt Brainerd
>>>       
>> -- 
>> Cheers!
>>
>> Dan Nagle
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> J3 mailing list
>> J3 at j3-fortran.org
>> http://j3-fortran.org/mailman/listinfo/j3
>>   
>>     
>
>