Fortran - F2k3 Environment Variable Support

Author

F2k3 Environment Variable Support

Gary Scott

2004-09-20, 4:02 pm

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.

Richard E Maine

2004-09-20, 4:02 pm

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

James Giles

2004-09-20, 4:02 pm

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

Richard E Maine

2004-09-20, 4:02 pm

"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

Gordon Sande

2004-09-20, 9:02 pm

Gary L. Scott

2004-09-21, 4:00 am

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

Gary L. Scott

2004-09-21, 4:00 am

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

James Giles

2004-09-21, 4:00 am

Gary L. Scott wrote:
> James Giles wrote:
....
[color=darkred]
> 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

Gary L. Scott

2004-09-21, 9:04 am

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

James Giles

2004-09-21, 3:58 pm

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

Ron Shepard

2004-09-21, 3:58 pm

In article <6dad5570.0409200706.297b08f3@posting.google.com>,
gary.l.scott@lmco.com (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.

The POSIX 1003.9 fortran interface in 1991 allows a fortran program
to both read and modify the environment. This standard has
apparently expired now. Nonetheless, it is always surprising to me
how many threads here in c.l.f where answered long ago with this
standard, from stream I/O to command line arguments to environment
variables. You might check your compiler documentation to see if
this POSIX standard is supported.

The new 2003 fortran standard does provide a mechanism to interface
to a C function, and reading and modifying the environment is
straightforward using C (and standard, at least for unix-like or
POSIX-like operating systems).

$.02 -Ron Shepard

TimC

2004-09-21, 8:57 pm

On Mon, 20 Sep 2004 at 19:33 GMT, Richard E Maine (aka Bruce)
was almost, but not quite, entirely unlike tea:
> "James Giles" <jamesgiles@worldnet.att.net> writes:
>
>
> 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).

I would say that there can be no way to put it in the standard,
because how a spawned child process behaves is so highly system
dependant.

Does the OS need a fork() and then system(), or does it do whatever
inefficient means Windows uses?

Does it not have the ability at all?

When they are different, then the fundamental behaviour of processes
will change. You won't be able to do *anything* with those processes
other than set them, and let them go, because the standard will never
go any further to say, eg. "hey, what's the status of process foo",
because what can Fortran possibly say what is meant by "status". What
signal it received when it died? Not defined on Windows.

I'd say the ability to set something, and leave it go, is not terribly
useful. I'd hope more for a new Posix standard that is actually
*useful*, and is actually implemented *correctly* at the same time.

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Cult: (n) a small, unpopular religion.
Religion: (n) a large, popular cult.

Richard Maine

2004-09-22, 3:58 am

TimC <tconnors@no.spam.accepted.here-astro.swin.edu.au> writes:
[about spawning processes]

> I would say that there can be no way to put it in the standard,
> because how a spawned child process behaves is so highly system
> dependant....

I disagree. We have other things just as system dependent. I see
no reason why we can't do this the same kind of way. Indeed, I
regard this as almost a dual problem to that of command-line
arguments, which we did add in f2003, which were widely requested,
and which are popular even in advance of f2003 compilers.

As with command-line arguments in f2003, a compiler would be free
to say that it just doesn't support the facility. All we would do
is provide a standardized spelling for those compiles that did want
to support it (which I'd suspect would be all or almost all of
them, since they all or almost all support something similar today).

> I'd say the ability to set something, and leave it go, is not terribly
> useful.

Well, I personally use system() and variants a lot today and find it
useful. So do many other people, as evidenced here and elsewhere.
All I'm looking for is to standardize its spelling (and to leave
the details as system-specific as they are today). Other things
might also be useful, but that doesn't mean this wouldn't be,

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

James Giles

2004-09-22, 3:58 am

TimC wrote:
....
> I would say that there can be no way to put it in the standard,
> because how a spawned child process behaves is so highly system
> dependant.

Well, I agree with Rich Maine that the feature is an obvious
candidate for inclusion in the standard. It's just that it usually
only makes sense if the program setting the environment also
spawns child processes. That could be why the setting
of environment variables was left out.

> Does the OS need a fork() and then system(), or does it do whatever
> inefficient means Windows uses?

Well, most system implementors find fork() and then exec()
(not usually system()) to be such an inefficient means that they
fudge on the fork(): usually *not* duplicating the whole parent
process, but only pretending to do so. They do this by marking
the whole of the parent as read-only pages (in the virtual memory
management tables) and having both the parent and child processes
use the same swap image. A copy of the process' image is done
a page at a time, and only when one or other process changes a
particular page. If the child calls exec() almost immediately (the
usual thing), the original process' pages are then marked back to
their original privilages and the child gets associated with the
executable image of the new process. I'm not sure that anything
windows can do will be as messy or inefficient as that (but, it
doesn't pay to underestimate how inefficient Microsoft can be).

This is not to promote Windows, but the UNIX mechanism can
hardly be praised for its efficiency!

--
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

TimC

2004-09-22, 3:58 am

On Wed, 22 Sep 2004 at 03:10 GMT, James Giles (aka Bruce)
was almost, but not quite, entirely unlike tea:
> TimC wrote:
> ...
>
> Well, I agree with Rich Maine that the feature is an obvious
> candidate for inclusion in the standard. It's just that it usually
> only makes sense if the program setting the environment also
> spawns child processes. That could be why the setting
> of environment variables was left out.

I was of course, talking about system(). I agree that if one
implements command line args in the standard, env variables should be
there too (hell, they're defined in the C standard - main(int
argc,char **argv,char **envp))

But I disagree with Richard (?) about the usefulness of env vars. But
then again, I grew up in Unix-land.

Thank goodness for a user overridable PATH and LD_LIBRARY_PATH :)

>
> Well, most system implementors find fork() and then exec()
> (not usually system()) to be such an inefficient means that they
> fudge on the fork():

I wouldn't exactly call copy-on-write a fudge.

Of course, I would also say that any system that didn't do this rather
inferior. Imagine copying a 128MB process image, only to exec()
straight away!

That's why they first came up with vfork() decades ago, and then
people started doing COW. Of course, on the Linux Kernel Mailing List,
people are now talking about copy-on-write filesystems. Can you
imagine copying an entire directory tree with gigabytes in it
(incidentally, I just ran gzip over a single directory lastnight, and
managed to recover 35GB of disk space -- which is why I would like the
ability to open a pipe using an popen equivalent that operates on a
Fortran lun instead of a filehandle -- so I can run gzip
transparently), via a few syscalls, and not have to worry about actual
disk usage and time taken until one actually modifies files in the new
(or old) tree?

> executable image of the new process. I'm not sure that anything
> windows can do will be as messy or inefficient as that (but, it
> doesn't pay to underestimate how inefficient Microsoft can be).

I can't remember the details, but I know Linux is order of magnitudes
faster at creating processes via the canonical means than what Windows
does with it's create_process. The fact that creating a process has
been relatively cheap on Unix for decades is the reason why scripting
languages are so popular on said platform. I rarely feel the effect of
the thousands of fork()/exec() pairs that happen in each of the
thousands of shell scripts I have.

> This is not to promote Windows, but the UNIX mechanism can
> hardly be praised for its efficiency!

The unix mechanism of 30 years ago. Next you'll be telling me FORTRAN
is crap because it doesn't have control structures :)

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
vi is [[13~^[[15~^[[15~^[[19~^[[18~^ a
muk[^[[29~^[[34~^[[26~^[[32~^ch better editor than this emacs. I know
I^[[14~'ll get flamed for this but the truth has to be
said. ^[[D^[[D^[[D^[[D ^[[D^[^[[D^[[D^[[B^
exit ^X^C quit :x :wq dang it :w:w:w :x ^C^C^Z^D
-- Jesper Lauridsen <rorschak@daimi.aau.dk> from alt.religion.emacs

James Giles

2004-09-22, 3:58 am

TimC wrote:
....
> I can't remember the details, but I know Linux is order of magnitudes
> faster at creating processes via the canonical means than what Windows
> does with it's create_process. [...]

It's been a while, but the benchmarks I've seen are that Linux is rather
less efficient than other UNIXes (many web servers can handle significantly
more traffic largely because creating processes and switching between
them is *slow* on Linux). Not apropos of Windows (I can't remember
how it compared). An experimental non-UNIX implementation ran circles
around all of them, so it's not like non-Linux UNIX is all that superior.

>
> The unix mechanism of 30 years ago. Next you'll be telling me FORTRAN
> is crap because it doesn't have control structures :)

I was referring to the copy-on-write fudge as being inefficient
and cumbersome. The very existence of fork() as separate from
exec() is silly. There's no practical value in having a copy of
an existing process at all.

--
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

TimC

2004-09-22, 3:58 am

On Wed, 22 Sep 2004 at 04:55 GMT, James Giles (aka Bruce)
was almost, but not quite, entirely unlike tea:
> I was referring to the copy-on-write fudge as being inefficient
> and cumbersome. The very existence of fork() as separate from
> exec() is silly. There's no practical value in having a copy of
> an existing process at all.

That's a generalisation!

What about largly identical web server processes? The only difference
between them is the source/desnination, and URI. Makes sense to fork()
in that cases, doesn't it?

Particularly when the children don't need to communicate anything
other than success/failure back to the parent.

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Disclaimer: Due to feline interference, this post may contain typographical
errors.

James Giles

2004-09-22, 3:58 am

TimC wrote:
> On Wed, 22 Sep 2004 at 04:55 GMT, James Giles (aka Bruce)
> was almost, but not quite, entirely unlike tea:
>
> That's a generalisation!
>
>
> What about largly identical web server processes? The only difference
> between them is the source/desnination, and URI. Makes sense to fork()
> in that cases, doesn't it?

Ah yes, now I remember. That was the reason given that Linux was
slower than the other implementations of web servers.

--
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

TimC

2004-09-22, 3:58 am

On Wed, 22 Sep 2004 at 05:45 GMT, James Giles (aka Bruce)
was almost, but not quite, entirely unlike tea:
> TimC wrote:
>
> Ah yes, now I remember. That was the reason given that Linux was
> slower than the other implementations of web servers.

I'd actually blame it on the hardware - are you talking about Linux on
i386 vs sunOS on suns, etc?

The 386 hardware sucks in so many different ways - and it is true its
MMU is one of those areas.

Unfortuantely, our next cluster looks like it will be P4's instead of
opterons. At least the opterons were getting almost as quick as the 3
or 4 year old alpha EV68s on my code. The p4s were honestly 4 times
slower. And having a dual CPU was useless -- it added about 10%
increase in speed on my 16 processor MPI job, over just having 8
processors in seperate machines. Yet they cost twice as much.

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS d- s:- a-- C+++(++++) UL(SOBI)+++(++++) P+++ L+++ E++(----)
W++(--) N+++ o K+++ w---(++) O- M--(+) V PS++ PE-(--) Y PGP t->+
!5 X R? tv- b- DI+ D--- G e++>++++ h* r(--) !y+
------END GEEK CODE BLOCK------

James Giles

2004-09-22, 3:58 am

TimC wrote:
> On Wed, 22 Sep 2004 at 05:45 GMT, James Giles (aka Bruce)
> was almost, but not quite, entirely unlike tea:
>
> I'd actually blame it on the hardware - are you talking about Linux on
> i386 vs sunOS on suns, etc?

Since the tests were conducted on identical hardware. that's pretty
unlikely.

--
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

Jan Vorbrüggen

2004-09-22, 3:58 am

> 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.

That has not been true on any Unix shell I have been using.

Jan

Jan Vorbrüggen

2004-09-22, 3:58 am

> I can't remember the details, but I know Linux is order of magnitudes
> faster at creating processes via the canonical means than what Windows
> does with it's create_process.

That is an urban legend. It partly resulted from the comparison of VMS
against Unix in this regard, which had the major problem of comparing
apple seeds to whole apples.

Under the hood, all approaches necessarily do almost the same thing: it
so happens that even one important but obscure detail of the implementation
is the same for VMS and Unix on VAX...so there.

Jan

TimC

2004-09-22, 9:09 am

On Wed, 22 Sep 2004 at 07:14 GMT, James Giles (aka Bruce)
was almost, but not quite, entirely unlike tea:
> TimC wrote:
>
> Since the tests were conducted on identical hardware. that's pretty
> unlikely.

Fair enough.

Doesn't stop me from hating i386 :)

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
DJ - "Isn't it pathetic to quote yourself?"
David Barnes - "No, not when you are as good as me"

James Giles

2004-09-22, 9:09 am

Jan Vorbrüggen wrote:
>
> That has not been true on any Unix shell I have been using.

Well, it has been a while since I used any flavor of UNIX
extensively, but if one process can change the values of
environment variables as used by another, unrelated
process (that is, neither is the child of the other, directly
or indirectly), then that makes me distrust environment
variables more than before. But, how do the shells you
talk about work? The only way to pass the environment
to a new process is though the operation of the exec()
system call. There are six varieties of exec() in my (old)
POSIZ doc. Three allow the process to define a new
environment for the program that's starting, and three just
pass along a copy of the existing environment. How would
using any of those make global changes to any unrelated
processes?

--
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

Jan Vorbrüggen

2004-09-22, 9:09 am

>>>The only ones globally visible are those
>
> Well, it has been a while since I used any flavor of UNIX
> extensively, but if one process can change the values of
> environment variables as used by another, unrelated
> process (that is, neither is the child of the other, directly
> or indirectly), then that makes me distrust environment
> variables more than before.

But that's not what you said, initially (and quoted above). The point
is that you can modify the current process's environment variables in
ways seperate from "the appropriate init file" - both from the shell
command line and from programs. Aside from kernel-mode hacking, I know
of no way to change it for an unrelated (as defined) above process, but
then that would not make sense anyhow...well, you could say that system-
or cluster-wide logical names in VMS serve that purpose, and they certainly
_are_ very useful.

Jan

Richard E Maine

2004-09-22, 4:01 pm

TimC <tconnors@no.spam.accepted.here-astro.swin.edu.au> writes:

> But I disagree with Richard (?) about the usefulness of env vars. But
> then again, I grew up in Unix-land.

I may have

people by switching between two different topics.
The thing that I was most emphasizing the usefulness of was system(),
rather than env variables. I use system() quite frequently. I've
used env variables on occasion, but those occasions are fairly rare.
One place I used them was to control my own run-time debugging options
or other things not intended for normal users.

I did mention that saw reading env variables as far more widely needed
than writing them, whch is a comment on usefulness, so I suppose that
could be what you are referring to.

Or maybe it was a poster other than me, as you do indicate that
possibility with your (?).

--
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

2004-09-22, 9:00 pm

Jan Vorbrüggen wrote:
>
> But that's not what you said, initially (and quoted above). [...]

I thought it was what I said initially. I still do.

> [...] The point
> is that you can modify the current process's environment variables in
> ways seperate from "the appropriate init file" - both from the shell
> command line and from programs. [...]

And I made that point. None of those modifications are "globally"
visible. They are only visible within the current process and it's
child processes.

> [...] Aside from kernel-mode hacking, I know
> of no way to change it for an unrelated (as defined) above process, but
> then that would not make sense anyhow... [...]

That was the gist of my statement. I was responding to the suggestion
that setting environment variables had some use *other* than to pass
data to the process' own descendents (well, a process could use them
to share data with itself I suppose). Perhaps I made an error in
adopting the other person's use of the word "global"? Certainly
"global" changes in the sense that he mentioned are something that
UNIX can't do and which I oppose.

--
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

glen herrmannsfeldt

2004-09-22, 9:00 pm

James Giles wrote:

(snip)

> That was the gist of my statement. I was responding to the suggestion
> that setting environment variables had some use *other* than to pass
> data to the process' own descendents (well, a process could use them
> to share data with itself I suppose). Perhaps I made an error in
> adopting the other person's use of the word "global"? Certainly
> "global" changes in the sense that he mentioned are something that
> UNIX can't do and which I oppose.

It would sometimes be nice if there were an easy way for programs
to change the environment of the parent shell. The programs that
need to do it (tset, and the X11 resize command) output shell commands
that must be then executed by the shell,

eval `/usr/X11/bin/resize`

and the program must know which shell is being used.

Otherwise, yes, separate environment is a nice feature.

-- glen

James Giles

2004-09-22, 9:00 pm

glen herrmannsfeldt wrote:
.....
> It would sometimes be nice if there were an easy way for programs
> to change the environment of the parent shell. The programs that
> need to do it (tset, and the X11 resize command) output shell commands
> that must be then executed by the shell,
>
> eval `/usr/X11/bin/resize`
>
> and the program must know which shell is being used.

Well, yes. And it's sometimes nice to have my front door
unlocked when I get home so I don't have to fumble with
keys. But, I don't think the keys are a large price to par
for at least a minimum of security.

--
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

glen herrmannsfeldt

2004-09-22, 9:00 pm

James Giles wrote:

> glen herrmannsfeldt wrote:

[color=darkred]
[color=darkred]
> Well, yes. And it's sometimes nice to have my front door
> unlocked when I get home so I don't have to fumble with
> keys. But, I don't think the keys are a large price to par
> for at least a minimum of security.

But you do have a key! The eval method is more like
requiring you to climb through a window.

-- glen

Gary L. Scott

2004-09-22, 9:00 pm

James Giles wrote:
> Jan Vorbr=FCggen wrote:
>=20
>=20
>=20
> I thought it was what I said initially. I still do.
>=20
>=20
>=20
>=20
> And I made that point. None of those modifications are "globally"
> visible. They are only visible within the current process and it's
> child processes.
>=20
Then at a minimum it should behave as for c's putenv:

http://www.digitalmars.com/rtl/overview.html

My behavior preference is for CVF's setenvqq. Barring an OS' inability=20
to do that, then at least there is a consistent spelling and argument=20
list for the facility.

>=20
>=20
[color=darkred]
>=20
>=20
> That was the gist of my statement. I was responding to the suggestion
> that setting environment variables had some use *other* than to pass
> data to the process' own descendents (well, a process could use them
> to share data with itself I suppose). Perhaps I made an error in
> adopting the other person's use of the word "global"? Certainly
> "global" changes in the sense that he mentioned are something that
> UNIX can't do and which I oppose.
>=20

--=20

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

2004-09-22, 9:00 pm

glen herrmannsfeldt wrote:
> James Giles wrote:
>
>
>
>
>
> But you do have a key! The eval method is more like
> requiring you to climb through a window.

Not quite. It's more like someone already in the house letting
me in.

The point is that nothing in the process can directly set environment
variables in its parent. The parent must receive those changes (perhaps
though the alternative communication you mentioned) and explicitly
install them (perhaps with the eval feature you mention). A malicious
or erroneous process can't just change the parent's environment invisibly.

--
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

Walter Spector

2004-09-23, 3:56 am

"Gary L. Scott" wrote:
> Then at a minimum it should behave as for c's putenv:

The POSIX setenv would be a better start. The putenv routine is
not part of ANSI C, and I do not think it is part of POSIX either.

> My behavior preference is for CVF's setenvqq. Barring an OS' inability
> to do that, then at least there is a consistent spelling and argument
> list for the facility.

As Ron Shepard mentioned, there already is a Standardized spelling on
systems which support POSIX 1003.9: PXFSETENV. Here is its signature:

interface
subroutine pxfsetenv (name, lenname, new, lennew, ioverwrite, ierror)
character(*), intent(in) :: name
integer, intent(in) :: lenname
character(*), intent(in) :: new
integer, intent(in) :: lennew
integer, intent(in) :: ioverwrite
integer, intent(out) :: ierror
end subroutine
end interface

Where:

name = env variable name to be created/replaced
lenname = # of significant characters in 'name' (use 0 to ignore trailing blanks)
new = value to be used
lennew = # of significant characters in 'new' (0 to ignore trailing blanks)
ioverwrite = if non-zero, allow overwrite of existing variable
ierror = if non-zero, an error occurred

If your vendor of choice does not support POSIX.9, it is usually trivial to
write ones own pxfsetenv. My home-written version of pxfsetenv (runs under cygwin
and works with g77 - soon to also work with Salford FTN95) is about 30 lines long.

Another way of changing a processes memory is via the debugger
interface (e.g., /proc)...

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Dave Thompson

2004-09-27, 3:57 am

On Wed, 22 Sep 2004 03:42:33 GMT, TimC
<tconnors@no.spam.accepted.here-astro.swin.edu.au> wrote:
<snip>
> I was of course, talking about system(). I agree that if one
> implements command line args in the standard, env variables should be
> there too (hell, they're defined in the C standard - main(int
> argc,char **argv,char **envp))
>
In the C standard _document_ as a common extension, C90 annex G or C99
J, but not standard in C, nor even in POSIX/SUS, although the latter
adds extern char **environ and putenv to Standard C's getenv.

- David.Thompson1 at worldnet.att.net

Sponsored Links