Hi,

No, don't pull out the "export FOO=BAR" answers just yet...

I'm trying to set an environment variable of the current shell process.
Using "export FOO=BAR" doesn't work, the variable FOO will then only
be set in the environment of child processes of the shell. An example:

First, verify $FOO isn't currently set as a shell variable:

$ export | grep -q FOO && echo found
$

Also verify it isn't part of the current environment:

$ ps geww $$ | grep -q FOO && echo found
$

So, neither $FOO is set, nor is FOO part of the environment. Now let's
set $FOO, and check again:

$ export FOO=BAR
$ export | grep -q FOO && echo found
found
$ ps geww $$ | grep -q FOO && echo found
$

So, $FOO is now set, but FOO still isn't part of the environment of the current
shell proces. When I start a new shell, this changes:

$ ksh
$ export | grep -q FOO && echo found
found
$ ps geww $$ | grep -q FOO && echo found
found
$

In the new process, FOO is set as an environment variable, and $FOO is set as
a shell variable.


I'm looking for a way to influence the environment of the current shell
process. In Perl, it's easy to influence the environment of the running
proces: $ENV{FOO}="BAR". I have the feeling I'm overlooking something quite
basic... It isn't specific to AIX ksh, the OpenBSD ksh behaves the same.
Doing an exec of ksh works, but that's more of a workaround. There must be
a cleaner solution.

If someone has a tip about how to influence the environment of the current
shell, that would be great...

--
Jurjen Oskam

Savage's Law of Expediency:
You want it bad, you'll get it bad.

Jurjen Oskam wrote:
> Hi,
>
> No, don't pull out the "export FOO=BAR" answers just yet...
>
> I'm trying to set an environment variable of the current shell process.
> Using "export FOO=BAR" doesn't work, the variable FOO will then only
> be set in the environment of child processes of the shell. An example:
>
> First, verify $FOO isn't currently set as a shell variable:
>
> $ export | grep -q FOO && echo found
> $
>
> Also verify it isn't part of the current environment:
>
> $ ps geww $$ | grep -q FOO && echo found
> $
>
> So, neither $FOO is set, nor is FOO part of the environment. Now let's
> set $FOO, and check again:
>
> $ export FOO=BAR
> $ export | grep -q FOO && echo found
> found
> $ ps geww $$ | grep -q FOO && echo found
> $
>
> So, $FOO is now set, but FOO still isn't part of the environment of the current
> shell proces. When I start a new shell, this changes:
>
> $ ksh
> $ export | grep -q FOO && echo found
> found
> $ ps geww $$ | grep -q FOO && echo found
> found
> $
>
> In the new process, FOO is set as an environment variable, and $FOO is set as
> a shell variable.
>
>
> I'm looking for a way to influence the environment of the current shell
> process. In Perl, it's easy to influence the environment of the running
> proces: $ENV{FOO}="BAR". I have the feeling I'm overlooking something quite
> basic... It isn't specific to AIX ksh, the OpenBSD ksh behaves the same.
> Doing an exec of ksh works, but that's more of a workaround. There must be
> a cleaner solution.
>
> If someone has a tip about how to influence the environment of the current
> shell, that would be great...
>

Have you tried setting the variable in .profile? If I set a variable in
..profile and then use 'set' to display the environment they show as the
value I used.

On 17 Apr., 22:59, Jurjen Oskam <jur...@stupendous.org> wrote:
> I'm trying to set an environment variable of the current shell process.
> Using "export FOO=BAR" doesn't work, the variable FOO will then only
> be set in the environment of child processes of the shell. An example:

a process can alter its own environment via the putenv() system call.
your shell just keeps its own list of variable/value pairs and puts
the exported ones into the environment of spawned child processes.
perl language designers have included a language element to allow you
to do putenv() whereas shell language designers seem to have not done
so.
but why would you care? what would a (hypothetical) "shell_putenv()"
give you that is superior to "FOO=BAR" or "export FOO=BAR" ?

Joachim

On 17 Apr., 22:59, Jurjen Oskam <jur...@stupendous.org> wrote:
> Hi,
>
> No, don't pull out the "export FOO=BAR" answers just yet...
>
> I'm trying to set an environment variable of the current shell process.
> Using "export FOO=BAR" doesn't work, the variable FOO will then only
> be set in the environment of child processes of the shell. An example:

a process can alter its own environment via the putenv() system call.
your shell keeps its own list of name/value pairs (seperate from its
own environment) and copies the exported ones to the environment of
spawned child processes.
perl language designers have included a language element to allow
scripts to use putenv() whereas shell language designers seem to have
not done so.
but why would you care? what would make a (hypothetical)
"shell_putenv" superior to a "FOO=BAR" or "export FOO=BAR"?

Joachim

On 2008-04-18, Joachim Gann <joachim.gann@gmail.com> wrote:

> would you mind sharing the reason with us why "export FOO=bar" is not
> sufficient for you?

I already did, in slrng0h6ot.8am.jurjen@calvin.stupendous.org
(http://groups.google.com/group/comp....b546661b97a17).

Short version: I was trying to look at exported shell variables (thinking they
were environment variables) from other processes, and this doesn't work
when the shell doesn't actually put exported shell variables in the
environment of the current shell.

But it's no big deal, I'll find another way to achieve my original goal.
It just surprised me (and seeing the reactions, it surprised some other
people as well ), and I became curious.

--
Jurjen Oskam

Savage's Law of Expediency:
You want it bad, you'll get it bad.

Jurjen Oskam wrote:
> On 2008-04-18, sjm <sjm_news@yahoo.co.uk> wrote:
>
>> The key to all this is that shell variables and environment variables
>> are in fact distinct and not the same. The shell is working on shell
>> variables and perl on the environment. Use the source luke ...
>
> True, but an afwul lot of documentation implies or outright states that
> a shell variable which is exported *is* an environment variable.
>
> For example, here's a piece of the official AT&T ksh manpage (emphasis mine):
>
> [...] The environment (see environ(7)) is a list of name-value pairs that is
> passed to an executed program in the same way as a normal argument list.
> [...] The shell interacts with the environment in several ways. On invocation,
> the shell scans the environment and creates a variable for each name found,
> giving it the corresponding value and marking it export. Executed commands
> inherit the environment. *If the user modifies the values of these variables
> or creates new ones, using the export or typeset-x commands they become part
> of the environment*. [...]
>
> (Also, using the source is a bit difficult on a closed-source OS such as AIX.)
>

Which is one of the many reasons having bash or ksh available as source
is so cool, eh what?

On Apr 18, 1:10 pm, Jurjen Oskam <jur...@stupendous.org> wrote:

> This indeed seems to be the case. Even when changing the value of an
> environment variable the shell only updates its own internal variable, so
> you end up with different values...
>
> Makes me wonder why this is the case, and it makes the term "environment
> variable" a bit ambiguous when the shell is involved.

export only marks variables for export to commands that will be
executed in the future
this allows the shell implementation to manage its variables (export
and non-export) much
more efficiently than most putenv(3) implementations

from the posix export man page:

The shell shall give the export attribute to the variables
corresponding to the specified names, which shall cause
them to be in the environment of subsequently executed
commands. If the name of a variable is followed by = word, then the
value of that variable shall be set to word.

-- Glenn Fowler -- AT&T Research, Florham Park NJ --