Garbled string created from an environment variable with underscore character #47714
Description
Version
18.10.0
Platform
Linux battlestation 6.2.7-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 17 16:16:00 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
String management
What steps will reproduce the bug?
- Set an environment variable with an underscore in its name:
export NODE_ENV=development
- Use the value of this environment variable for any string operation:
const filename = `settings.${process.env.NODE_ENV}.json`);
console.log(filename);How often does it reproduce? Is there a required condition?
It reproduces every time you run the above snippet in a Linux environment.
Required condition is to use an environment var with an underscore character in its name.
What is the expected behavior? Why is that the expected behavior?
It should output a proper string. Something like:
settings.development.json
What do you see instead?
The resulting string will be garbled, and any substring after the inserted environment variable will appear at index 0 instead of where it's supposed to. For me, it looks like this:
.jsonings.development
Additional information
Curiously, the bug only happens if the environment variable has an underscore in its name. It does not occur without an underscore (ie. NODEENV), and it also doesn't occur with a "regular" variable or a hardcoded string value. It also doesn't occur on Windows.
The bug seems to "poison" any string created from the environment variable. No matter how a new string is created, if it ever included the environment var with the underscore, it will glitch out.
It appears that an extra character is inserted into the faulty strings:
let settingsPath = '/settings.' + process.env.NODE_ENV + '.json';
console.log(settingsPath);
console.log(settingsPath.length);
// Output:
// .jsonings.development
// 27
for (let t=0; t<settingsPath.length; t++) {
console.log(`${t} ${settingsPath.charCodeAt(t)} ${settingsPath[t]}`);
}
This shows that the extra character is appearing right after the inserted string, and it's a CR (ASCII 13).
The workaround is, therefore, is to strip line breaks from environment variable values. But it's still a bug.