Cath envp into a sub routine/module.

[Pim]

Hi all.
I want to get my environment, but inside a function that receive no
parameters from any call from the main function.

i mean some code that could catch environment other than access
to envp.... or trick to access envp outside the main fonction.

.... if this is possible of course.

I thank you very much.

Pim.

 

[Eric Sosman]

Hi all.
I want to get my environment, but inside a function that receive no
parameters from any call from the main function.

i mean some code that could catch environment other than access
to envp.... or trick to access envp outside the main fonction.

... if this is possible of course.

From any place in the program, you can use getenv() to get
the value of any environment variable whose name you already know.

Standard C has no way to list all the environment variables
and their values (aside from the impractical subterfuge of generating
all possible variable names and calling getenv() on each of them, one
by one). Other applicable standards may provide a means to do this:
POSIX, for example, has the external variable `char **environ' that
provides a way to traverse the entire environment, and other O/S'es
may have similar capabilities. If you need them, ask about them in
a forum dedicated to the O/S: comp.unix.programmer for POSIX systems,
for example.

 

[Pim]

Le Sat, 12 Jun 2010 15:41:19 -0400,

From any place in the program, you can use getenv() to get
the value of any environment variable whose name you already know.

Standard C has no way to list all the environment variables
and their values (aside from the impractical subterfuge of generating
all possible variable names and calling getenv() on each of them, one
by one). Other applicable standards may provide a means to do this:
POSIX, for example, has the external variable `char **environ' that
provides a way to traverse the entire environment, and other O/S'es
may have similar capabilities. If you need them, ask about them in
a forum dedicated to the O/S: comp.unix.programmer for POSIX systems,
for example.

YESS!!!
Just got the same answer on the same N.G , french version.
I think i'll use **environ , and 'll ask there on unix N.G if needed.
Thank you very much Eric.
jean-yves.

 

[Billy Mays]

Hi all.
I want to get my environment, but inside a function that receive no
parameters from any call from the main function.

i mean some code that could catch environment other than access
to envp.... or trick to access envp outside the main fonction.

... if this is possible of course.

I thank you very much.

Pim.

If you can pipe the output of your shell (if your program is invoked
from a shell) then you can usually get your environment variables back.
In Windows you can use the ' system("SET"); ' call you get the
environment vars and in *nix it is (or at least in bash) its '
system("env"); '.

If you can pipe the output of either of those two calls you can parse
the KV pairs.

Bill

 

[Keith Thompson]

If you can pipe the output of your shell (if your program is invoked
from a shell) then you can usually get your environment variables back.
In Windows you can use the ' system("SET"); ' call you get the
environment vars and in *nix it is (or at least in bash) its '
system("env"); '.

If you can pipe the output of either of those two calls you can parse
the KV pairs.

Calling system() with a platform-specific command is non-portable.
Using an OS-provided mechanism to get the environment is going
to be much more efficient, and doesn't make your program any less
portable than it already is.

 

[Billy Mays]

Calling system() with a platform-specific command is non-portable.
Using an OS-provided mechanism to get the environment is going
to be much more efficient, and doesn't make your program any less
portable than it already is.

I must disagree here. The system command is standard while OS specific
calls are not. You could potentially run multiple 'system()' calls
which would fail until you found one that worked, rather than not even
compiling if moved to a different OS.

Example:

if( !system("env") )
{
/* *nix code */
}
else if( !system("set") )
{
/* Windows code */
}
else
{
/* ... */
}


This would also minimize the number of extra headers you might have to
include. Unless it is possible that a bad shell command could crash the
calling program, I don't see this as a problem. Also, you would have to
be calling this ALOT before you saw any specific speed related problems.

Bill

 

[Tom St Denis]

I must disagree here.  The system command is standard while OS specific
calls are not.  You could potentially run multiple 'system()' calls
which would fail until you found one that worked, rather than not even
compiling if moved to a different OS.

Except that

a) You could invoke behaviour that is undefined by calling apps.
Maybe my platform has both "set" and "env" commands (hint hint) and
maybe "set" on my platform doesn't produce output like you want.

b) Maybe I don't give you a shell so all calls to system() fail.

The getenv() route seems the most likely to be as far reaching as
possible.

Tom

 

[Keith Thompson]

A valid point, ...

Except that

a) You could invoke behaviour that is undefined by calling apps.
Maybe my platform has both "set" and "env" commands (hint hint) and
maybe "set" on my platform doesn't produce output like you want.

Or maybe the user has added a "set" or "env" command that produces
output in a different format, or that does something entirely
different. Or maybe the user's search path ($PATH, %PATH%, whatever)
is messed up, and the "set" or "env" command that should normally
be available isn't.

b) Maybe I don't give you a shell so all calls to system() fail.

The getenv() route seems the most likely to be as far reaching as
possible.

Except that getenv() can't give you a list of *all* environment
variables; it only gives you the value of an environment variable
whose name you already know. (Checking all possible names is
impractical.)

Most programs probably don't need to look at environment variables
they don't already know about. But if you need a list of all
environment variables and their values, you have to do something
system-specific. The point is that system("whatever") is not the
best system-specific solution.

Note that POSIX-specific solutions, while they're not portable to
all C implementations, are likely to be usable on more than just
Unix-like systems.