Skip to content

Questionable internal casing of property name process.env.Path #20605

Closed
@JamesMGreene

Description

@JamesMGreene
  • Version: v8.11.1 (but affects all versions AFAIK)
  • Platform: Windows 10 Enterprise x64
  • Subsystem: process, child_process

There is some quirky-ness regarding the property name casing of process.env.PATH (which is actually cased as Path, it seems) and/or the usage of it via the child_process module, e.g. in child_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 of process.env to child_process.spawn (etc.).

Using the Node REPL:

> var childProcess = require('child_process');

> Object.keys(process.env).filter(k => k.toUpperCase() === 'PATH')
[ 'Path' ]

> process.env.PATH = 'C:\\Python27';
'C:\\Python27'

> childProcess.spawnSync('python', ['--version']).stderr.toString().trim()
'Python 2.7.11'

> let env = { ...process.env };  // a.k.a. `Object.assign({}, process.env);`
undefined

> Object.keys(env).filter(k => k.toUpperCase() === 'PATH')
[ 'Path' ]

> env.PATH
undefined

> env.Path
'C:\\Python27'

// ISSUE: Node unexpectedly using `process.env.PATH` instead of `options.env.Path`
> childProcess.spawnSync('python', ['--version'], { env }).stderr.toString().trim()
'Python 2.7.11'

> process.env.PATH = '';
''

// ISSUE: Node unexpectedly using `process.env.PATH` instead of `options.env.Path`
> childProcess.spawnSync('python', ['--version'], { env }).stderr.toString().trim()
TypeError: Cannot read property 'toString' of null

> env.PATH = env.Path;
'C:\\Python27'

> childProcess.spawnSync('python', ['--version'], { env }).stderr.toString().trim()
'Python 2.7.11'

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 into envPairs (an array of ${key}=${value} strings), that are then utilized by "process_wrap.cc"'s Spawn method as env_pairs, so I didn't see anywhere where there is an expectation of having an uppercase PATH variable available at all. 😕

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions