see env(3), basically the rfork flags affect it. check the man page.
On Jun 8, 2012, at 8:02 PM, Friedrich Psiorz wrote:
> hi! I'm new to Plan 9 and I don't understand this behavior:
>
> I wrote a program that basically just does
> putenv("foo", "bar");
>
> After running it,
> echo $foo
> print
hi! I'm new to Plan 9 and I don't understand this behavior:
I wrote a program that basically just does
putenv("foo", "bar");
After running it,
echo $foo
prints just an empty line, while
cat /env/foo
prints bar. Can anyone explain?
I asked a somewhat same question a month back
http://9fans.net/
hi! I'm new to Plan 9 and I don't understand this behavior:
I wrote a program that basically just does
putenv("foo", "bar");
After running it,
echo $foo
prints just an empty line, while
cat /env/foo
prints bar. Can anyone explain?
generally, the correct answer is: don't do that.
it's better to treat subshells as if they exist
in a different scope, even if the environment
group isn't forked.
if you want to get values back from a script,
send them in its stdout.
2009/11/24 Rudolf Sykora :
>> the easy (and correct) answer is
>
> the easy (and correct) answer is
>exec rc
>
> - erik
>
> Well but this you can't do when being in the middle of a script
execution...
Can you?
Thanks
Ruda
> for(var in `{ls /env}) {
> ifs=() contents = `{cat /env/$var}
> if (~ $var *#*) fn `{echo $var | awk '{split($0, a, "#"); print a[1]}'}
> {$contents}
> if not var = $contents
> }
pretty sure that's a syntax error. and for simple variables, quite
wrong. this function does better, bu
>
> if you want to re-get the value of an environment variable,
> you can do:
>
> ifs=() var=`{cat /env/var}
>
Ok. So if one wants to update the rc's view of the environment, one must
write sth. along the lines
for(var in `{ls /env}) {
ifs=() contents = `{cat /env/$var}
if (~ $var *#*) fn
2009/11/23 Rudolf Sykora :
> Hello,
>
> If I have an rc script and I don't specify any rfork in it, then the
> namespace and the environment should be shared.
> So, having an 'a' script
>
> #!/bin/rc
> a = hello
> cd c #later on...
>
> and a 'b' script:
>
> #!/bin/rc
> a
> echo $a
>
> and running
> Rc forks a new process for every [non builtin] command it runs. To
> avoid such, use the . command to source the script instead of running
> it.
>
Ok. The thing about forking is clear. Yes, your suggestion of using . would
'solve' the problem of seeing the variables set in the 'a' script (called
2009/11/24 Rudolf Sykora :
> If I have an rc script and I don't specify any rfork in it, then the
> namespace and the environment should be shared.
> But it does not work like that, thanks to some
> caching or what. How should the 'b' script, or whatever, be corrected so
> that it work?
Rc forks
Hello,
If I have an rc script and I don't specify any rfork in it, then the
namespace and the environment should be shared.
So, having an 'a' script
#!/bin/rc
a = hello
cd c #later on...
and a 'b' script:
#!/bin/rc
a
echo $a
and running the 'b' script, I'd expect that the 'a' variable would
11 matches
Mail list logo
