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

Dan Nagle danlnagle at mac.com
Tue May 19 15:05:15 EDT 2009


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>
> Date: May 19, 2009 2:47:45 PM EDT
> To: danlnagle at mac.com
> Cc: "Brocci, R. A." <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
>
> 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. 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>  
> 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
>
>
>
>
> -- 
> Walt Brainerd

-- 
Cheers!

Dan Nagle




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20090519/734394ac/attachment.html 


More information about the J3 mailing list