Skip to content
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

[BUG] *.CMD shims don't work when they are in paths containing shell metachars #45

Open
joeywatts opened this issue Feb 20, 2020 · 4 comments · May be fixed by #53
Open

[BUG] *.CMD shims don't work when they are in paths containing shell metachars #45

joeywatts opened this issue Feb 20, 2020 · 4 comments · May be fixed by #53

Comments

@joeywatts
Copy link

joeywatts commented Feb 20, 2020

What / Why

Generated *.CMD files are unable to start correctly when the path to the CMD file contains certain characters.

When

  • Whenever the path contains a cmd.exe shell metacharacter (such as &).

Where

  • Any package with a "bin" entry.

How

Current Behavior

  • The shell metacharacters are parsed by the shell instead of the full argument being passed into node. With my npm prefix set to "C:/test(n&pm)" and after installing the mkdirp package globally, I see the following error when attempting to run "mkdirp" in cmd.exe.
'pm)\' is not recognized as an internal or external command,
operable program or batch file.
internal/modules/cjs/loader.js:969
    throw err;
    ^

Error: Cannot find module 'C:\test(n\node_modules\mkdirp\bin\cmd.js'
�[90m    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:966:17)�[39m
�[90m    at Function.Module._load (internal/modules/cjs/loader.js:859:27)�[39m
�[90m    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)�[39m
�[90m    at internal/main/run_main_module.js:17:47�[39m {
  code: �[32m'MODULE_NOT_FOUND'�[39m,
  requireStack: []
}

Steps to Reproduce

  • Orchestrate any scenario in which the .CMD files will be generated under a path containing "&" character (in theory the other shell metacharacters would also be problematic, see references for an article on windows command line escaping).

Two scenarios come to mind.

Scenario 1: Set NPM Prefix to New Path

  1. Set npm prefix to "C:/test(n&pm)"
  2. Globally install mkdirp (or any other binary package).
  3. Make sure "C:/test(n&pm)" is in your PATH.
  4. Attempt to run "mkdirp" (or whatever you installed).

Scenario 2: Local Dependencies

  1. Create an npm package in a folder like "C:/test(n&pm)/package"
  2. Install a local dependency which has a "bin" entry (like "mkdirp")
  3. Add a script to package.json which attempts to run the dependency's bin (like "trymkdir": "mkdirp mytestfolder")
  4. Attempt to run your script: npm run trymkdir

Expected Behavior

  • The .CMD files should be able to run without getting tripped up by shell metacharacters in the path.

Who

  • n/a

References

@wycats
Copy link

wycats commented Feb 29, 2020

This is a real issue (and well researched!). Any reason not to do this?

@isaacs
Copy link
Contributor

isaacs commented Feb 5, 2021

We recently made the shift in npm v7 to use puka for exactly this purpose when passing arguments to cmd.exe. (And in the process, seem to have broken passing empty strings with "" to npm scripts, which will likely be fixed soon.). Unfortunately, translating the logic required into batch and powershell is nontrivial.

Patch welcome!

Timsonrobl added a commit to Timsonrobl/npm-cmd-shim that referenced this issue Mar 28, 2021
in set command parametr value read from %~p* parameter extension needed to be quoted to avoid special characters from path breaking command
Timsonrobl added a commit to Timsonrobl/npm-cmd-shim that referenced this issue Mar 28, 2021
in set command parameter value read from %~p* parameter extension needed to be quoted to avoid special characters from path breaking command
@Timsonrobl Timsonrobl linked a pull request Mar 28, 2021 that will close this issue
@jcompagner
Copy link

jcompagner commented Aug 5, 2022

this commit: 4c37e04

caused this issue because this:

SET dp0=%~dp0

will result in a wrong dir if the path is something like c:\something&somemore\

thing is if i quoted it

SET dp0="%~dp0"

then it doesn't work further in the script because then the dp0 variable has quotes (a bit stupid of cmd...)
what we kind of want is get the full string without quotes

But for me kind of reverting that above commit works for me (so not using the "dp0" variable that has the content of ~dp0
but directly use ~dp0 everywhere..

@jcompagner
Copy link

what is exactly the problem with this pull request?
022fcf1

because that keeps the current behavior quite as is and seems to fix the problem
or does that really result in the same problem as issue #10 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants