-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Questionable internal casing of property name process.env.Path
#20605
Comments
I believe the issue is that libuv is looking for uppercase node/deps/uv/src/win/process.c Lines 826 to 839 in cf44abb
which is called from the following code to find the path of the application being spawned: node/deps/uv/src/win/process.c Lines 1010 to 1046 in cf44abb
cc @nodejs/libuv @nodejs/platform-windows |
Nice find, @richardlau! |
That said, how is it that |
Probably because this function sets any "missing" required environment variables: node/deps/uv/src/win/process.c Lines 667 to 824 in cf44abb
of which uppercase node/deps/uv/src/win/process.c Lines 48 to 60 in cf44abb
so if |
I would agree that seems to be what the code suggests but I also do not have Python in my OS-level |
At the OS level Lines 2618 to 2647 in b00c34c
Lines 2650 to 2679 in b00c34c
So if you set
|
Ah, that was the missing piece of the puzzle for me. 👌 |
fixes #474 amends #476 related to nodejs/node#20605
Refs: nodejs/node#20605 PR-URL: libuv#1837 Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This is kind of a note for myself since I haven't had time to look into this further, but thinking about this a bit more, I'm wondering if the libuv behaviour of using the passed in |
ping @richardlau should this stay open? |
Better documentation is always good and would be good enough to close this out. My last comment should probably still be investigated; if I remember correctly the libuv Windows code was using the path passed through in the env options to look up the command to execute which I don’t think is the case for Unix. |
…xe#481) fixes nexe#474 amends nexe#476 related to nodejs/node#20605
Fixes: #20605 Refs: libuv/libuv#1837 PR-URL: #32091 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Fixes: #20605 Refs: libuv/libuv#1837 PR-URL: #32091 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Fixes: #20605 Refs: libuv/libuv#1837 PR-URL: #32091 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
v8.11.1
(but affects all versions AFAIK)process
,child_process
There is some quirky-ness regarding the property name casing of
process.env.PATH
(which is actually cased asPath
, it seems) and/or the usage of it via thechild_process
module, e.g. inchild_process.spawn
.Does this internal casing of the property name as
Path
originate from Node.js or is that something that Node is provided by Windows/libuv
under the covers? It results in weird behavior when trying to pass in a copied version ofprocess.env
tochild_process.spawn
(etc.).Using the Node REPL:
I don't really understand how the difference is happening here. As far as I could tell looking through the Node.js core code, the
env
properties are enumerated and turned intoenvPairs
(an array of${key}=${value}
strings), that are then utilized by "process_wrap.cc"'sSpawn
method asenv_pairs
, so I didn't see anywhere where there is an expectation of having an uppercasePATH
variable available at all. 😕The text was updated successfully, but these errors were encountered: