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] Backslashes in additional arguments given to npm run scripts are escaped wrongly #3680

Closed
1 task done
c3er opened this issue Aug 23, 2021 · 2 comments · Fixed by npm/run-script#78
Closed
1 task done
Labels
Bug thing that needs fixing platform:windows is Windows-specific Priority 2 secondary priority issue Release 7.x work is associated with a specific npm 7 release

Comments

@c3er
Copy link

c3er commented Aug 23, 2021

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

Note: This bug is similar to #2638 but not the same.

Given the following package.json:

  "scripts": {
    "start": "node index.js"
  }
}

And this index.js:

console.log(process.argv)

Backslashes in additional arguments to npm start are escaped wrongly in most cases, i.e. the script gets via process.argv two backslashes for each given backslash.

Example:

$ npm start path\to\file

> start
> node index.js "path\\to\\file"

[
  'C:\\nodejs\\node.exe',
  'C:\\Users\\FlipperX\\Desktop\\tmp\\test\\index.js',
  'path\\\\to\\\\file'
]

If the additional argument is only a backslash, it works as expected:

$ npm start \

> start
> node index.js "\\"

[
  'C:\\nodejs\\node.exe',
  'C:\\Users\\FlipperX\\Desktop\\tmp\\test\\index.js',
  '\\'
]

Expected Behavior

Given the above example, process.argv should look like this:

[
  'C:\\nodejs\\node.exe',
  'C:\\Users\\FlipperX\\Desktop\\tmp\\test\\index.js',
  'path\\to\\file'
]

Steps To Reproduce

  1. In this environment...

Via CLI

  1. With this config...

package.json

  "scripts": {
    "start": "node index.js"
  }
}

index.js

console.log(process.argv)
  1. Run npm start path\to\file

  2. See error...

'path\\\\to\\\\file' instead of 'path\\to\\file'

Environment

  • OS: Windows 10 21H1 64 Bit
  • Node: 16.7.0 but also 14.17.5
  • npm: 7.19.1
@c3er c3er added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Aug 23, 2021
c3er added a commit to c3er/mdview that referenced this issue Aug 23, 2021
A workaround was added that addresses a problem that occurs only, if the
tool is started via an npm script at development time. The same
workaround lead the installed tool to fail at opening file in a Windows
share.

See npm/cli issue #3680 for more information.
npm/cli#3680
@arapoport
Copy link

I recently stumbled over this problem. npm 8.3.0 is affected too. npm 6.14.15 is not affected.

@silkfire
Copy link

Having the same problem with npx. Can someone look into this?

@nlf nlf added platform:windows is Windows-specific Priority 2 secondary priority issue and removed Needs Triage needs review for next steps labels May 5, 2022
luxuereal added a commit to luxuereal/md_viewer_electron that referenced this issue Jun 16, 2023
A workaround was added that addresses a problem that occurs only, if the
tool is started via an npm script at development time. The same
workaround lead the installed tool to fail at opening file in a Windows
share.

See npm/cli issue #3680 for more information.
npm/cli#3680
luxuereal added a commit to luxuereal/md_viewer_electron that referenced this issue Dec 12, 2023
A workaround was added that addresses a problem that occurs only, if the
tool is started via an npm script at development time. The same
workaround lead the installed tool to fail at opening file in a Windows
share.

See npm/cli issue #3680 for more information.
npm/cli#3680
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing platform:windows is Windows-specific Priority 2 secondary priority issue Release 7.x work is associated with a specific npm 7 release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants