aboutsummaryrefslogtreecommitdiffstats
path: root/lib/kernel
diff options
context:
space:
mode:
authorSverker Eriksson <[email protected]>2010-06-07 16:33:14 +0200
committerBjörn Gustavsson <[email protected]>2010-06-10 10:44:36 +0200
commit6925a0da3cf0fd299e5e468fd95c4d0a697b86ae (patch)
tree4c569b1a1b5edcac6d08e870959b2a81128e22fa /lib/kernel
parent12c4d172d373b743fcd4a61584ca2aaeb25cb926 (diff)
downloadotp-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 'lib/kernel')
0 files changed, 0 insertions, 0 deletions