Lars Balker Rasmussen wrote:
>
> # New Ticket Created by Lars Balker Rasmussen
> # Please include the string: [perl #23025]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23025 >
>
> There's no reason to test for the presence of setenv/unsetenv in libc
> - these functions are emulated if not present.
>
> However, now the 4th test fails on Solaris (and most likely other OS's
> witout setenv/unsetenv). This is because the test relies on a key
> disappearing from %ENV when it's been unsetenv'ed - this doesn't
> happen when using putenv("key=") as the current unsetenv emulation.
>
> I'm not sure what's the best portable way to handle this is.
a) Have config test for the existance of extern char **environ, or
possibly for extern char **_environ, and then emulate unsetenv by
mangling the contents of that variable. We might even try and get an
envp as a third argument to main(), and mangle that... I'm not sure
whether or not this would actually effect getenv(), though.
b) Use a hash to keep track of which keys we have deleted from %ENV.
When we want to know if a key exists in %ENV, first try to getenv() it,
and if it's an empty string (""), see if it's mentioned in the hash of
things we deleted from %ENV: if so, *claim* that the key doesn't exist.
Although (a) is unportable (and maybe a bit evil), sufficient testing
with Config might allow us to better fake unsetenv() on some systems.
Option (b) is quite portable, but is *definitely* slightly evil -- we'd
really only be deluding ourselves into thinking that the keys had been
deleted, but child processes, and anything in our own process which does
getenv directly (bypassing %ENV), will know that the "deleted" key is
really there.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
