F2k3 Environment Variable Support

Hi, it appears that F2k3 added support for retrieving "environment
variable" values.  Does it provide support for setting such values?  I
would need that ability about as often (not quite) as retrieving.

gary.l.scott@lmco.com (Gary Scott) writes:

> Hi, it appears that F2k3 added support for retrieving "environment
> variable" values.  Does it provide support for setting such values?

No.

> I would need that ability about as often (not quite) as retrieving.

I'd guess your case to be unusual then.  I've seen cases where setting
the values is desired, but I've generally seen that need as about an
order of magnitute rarer than that for getting values.

In any case, the answer is "No, that's not in the standard."

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Gary Scott wrote:
> Hi, it appears that F2k3 added support for retrieving "environment
> variable" values.  Does it provide support for setting such values?  I
> would need that ability about as often (not quite) as retrieving.


Setting environment variables is only useful if your Fortran
program spawns child processes.  Otherwise, on most systems
that have environment variables, any changes made will
disappear when the current process terminates and are not
visible to other processes.  If that is not the case, the
use of such a feature would be very system dependent and
non-portable.  Anyway, I see the feature as closely dependent
on spawning additional processes, which F2003 doesn't
include either.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"James Giles" <jamesgiles@worldnet.att.net> writes:

> ... spawning additional processes, which F2003 doesn't
> include either.

I tried to get that added in pretty late in the process, but
it didn't fly because of the lateness (at least that was the
most-cited reason for the votes against it).

It is on a list of proposals for the next standard... though that
list is currently just that - a list of proposals, rather than
an agreed-on list of things to be done.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

James Giles wrote:
> Gary Scott wrote:
> 
>
>
>
> Setting environment variables is only useful if your Fortran
> program spawns child processes.  Otherwise, on most systems
> that have environment variables, any changes made will
> disappear when the current process terminates and are not
> visible to other processes.  If that is not the case, the
> use of such a feature would be very system dependent and
> non-portable.  Anyway, I see the feature as closely dependent
> on spawning additional processes, which F2003 doesn't
> include either.
>

The limited version of "setting environment variables" is
returning a status code. That sounds like "STOP NN" which
has long been in Fortran. It even worked in (shudder!) JCL.

Richard E Maine wrote:

> gary.l.scott@lmco.com (Gary Scott) writes:
>
> 
>
>
> No.
>
> 
>
>
> I'd guess your case to be unusual then.  I've seen cases where setting
> the values is desired, but I've generally seen that need as about an
> order of magnitute rarer than that for getting values.
>
> In any case, the answer is "No, that's not in the standard."
>
Still, seems an incomplete solution.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

James Giles wrote:

> Gary Scott wrote:
> 
>
>
>
> Setting environment variables is only useful if your Fortran
> program spawns child processes.  Otherwise, on most systems
> that have environment variables, any changes made will
> disappear when the current process terminates and are not
> visible to other processes.  If that is not the case, the
> use of such a feature would be very system dependent and
> non-portable.  Anyway, I see the feature as closely dependent
> on spawning additional processes, which F2003 doesn't
> include either.
>
Some OS' actually apply them globally on a per userid basis.  They may
also be stored on disk and read from disk when enquired.  This allows a
limited form of interprocess communication.  I believe that NT can apply
them globally also (at least per user).

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Gary L. Scott wrote:
> James Giles wrote:
... 

> Some OS' actually apply them globally on a per userid basis.  They may
> also be stored on disk and read from disk when enquired.  This allows a
> limited form of interprocess communication.  I believe that NT can apply
> them globally also (at least per user).

But, if that's the mechanism, a better solution is to explicitly
read the data from files.  In any case, the situation you describe
is not portable.  How can the Fortran standard insist upon it?

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

James Giles wrote:

> Gary L. Scott wrote:
> 
>
> ...
> 
>
> 
>
>
> But, if that's the mechanism, a better solution is to explicitly
> read the data from files.  In any case, the situation you describe
> is not portable.  How can the Fortran standard insist upon it?
>
I think little investigation would reveal that it could be made to be
portable.  If you can set these globally or set the defaults for a "new
shell" (some OS' only have one shell), then that fits the bill.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Gary L. Scott wrote:
> James Giles wrote:
... 
> I think little investigation would reveal that it could be made to be
> portable.  If you can set these globally or set the defaults for a "new
> shell" (some OS' only have one shell), then that fits the bill.


Well, I'll have to take your word for it.  There's a couple
of 'if's in your claim.  I don't particulary like environment
variables anyway, so whether your proposed feature
worked or not I'd probably not use it.  I prefer things
to be a bit simpler.  I also prefer things more explicit:
environment variables always seem a bit covert.  Except
for the few parts they personally use, people never really
seem to know what's in their environment.  I've seen lots
of problems caused by things in there that the user didn't
even know about.  Letting them be permanently set by an
individual process (that might be in error - or even the
work of a virus or other malicious attack) seems to me a
way to make this worse.

I think this is one of the few things that UNIX actually
got right.  If you are going to have environment variables
at all (and *that* I don't think UNIX got right), their settings
should not be global, but limited to each process and its
descendents.  The only ones globally visible are those
set by the default initialization of each session - something
you can examine fully in the appropriate init file.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare