diff options
author | Sverker Eriksson <[email protected]> | 2010-06-07 16:33:14 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2010-06-10 10:44:36 +0200 |
commit | 6925a0da3cf0fd299e5e468fd95c4d0a697b86ae (patch) | |
tree | 4c569b1a1b5edcac6d08e870959b2a81128e22fa /erts/obj.debug | |
parent | 12c4d172d373b743fcd4a61584ca2aaeb25cb926 (diff) | |
download | otp-6925a0da3cf0fd299e5e468fd95c4d0a697b86ae.tar.gz otp-6925a0da3cf0fd299e5e468fd95c4d0a697b86ae.tar.bz2 otp-6925a0da3cf0fd299e5e468fd95c4d0a697b86ae.zip |
allow open_port with env vars with trailing '=' on Windows
Same problem that Steve Vinoski fixed for Unix. Similar fix done in
erts/emulator/sys/win32/sys_env.c for Windows.
Copy-paste from his commit-message:
The erlang:open_port spawn and spawn_executable directives can include
an {env, Env} directive to set up environment variables for the
spawned process. A bug in ert/emulator/sys/unix/sys.c prevented
applications from using {env, Env} to set an environment variable
whose value ended with a '=' (equal sign) character; the code mistook
the trailing equal sign as an indication that an environment variable
was to be cleared from the environment of the spawned process.
For example, passing an {env, Env} of
{env, [{"foo", "bar="}]}
would result in the code in sys.c seeing a string of the form
"foo=bar="
The code would see the final '=' character and assume the directive
wanted to clear a variable named "foo=bar" from the environment of the
spawned process, rather than seeing it as a directive to set the
environment variable "foo" to the value "bar=".
Diffstat (limited to 'erts/obj.debug')
0 files changed, 0 insertions, 0 deletions