-
-
Notifications
You must be signed in to change notification settings - Fork 233
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
escaping pass-through arguments is too eager #487
Comments
I've just cloned concurrently locally to create a build off current main branch, then linked it into that other project. $ git clone https://github.com/open-cli-tools/concurrently.git
$ cd concurrently
$ npm i
$ npm build
$ npm link Then, in my project: $ npm link concurrently The outcome is the same. |
Hey, thanks for the report. I'm willing to be more lenient with escaping/wrapping in quotes than the shell-quote package if it means having less bugs like yours. E.g. arguments with a space need wrapping, unless they're already wrapped, of course. But I'm not sure about the others, might need to go through the list below and reimplement it in concurrently: https://github.com/ljharb/shell-quote/blob/9eecafc0486c9321be223415cf3fb76a5bd07dda/quote.js#L14 (that said, I'm admittedly ignorant of risks of getting this wrong 😅 ) |
Well, I was hesitant to provide a solution I found based on my follow-up investigations as documented in the related issue at shell-quote repository for I was hoping to get a solution done there. However, since I wasn't able to wait for that with the original issue I was facing I've created a patched version of concurrently with shell-quote being replaced with my package. Maybe, I should provide it as a PR here. |
Background
When trying to use concurrently with
--passthrough-arguments
option, any passed arguments get escaped too eagerly.The issue has been observed while developing an application when trying to concurrently run a local web server and gherkin-testcafe for testing with the latter requring tags to start with @ character.
Since that application can't be shared here for legal reasons I've tried a simpler scenario which is reproducing the issue, too.
Scenario
Test
invoke without arguments
looks good ... setup is working as expected
invoke with arguments to pass
Problem here:
@
gets escapedEscaping seems to be eligible due to cmd.exe being involved. But eventually that escaping is found in invoked sub-process, too. Trying to fix it in that sub-process is not an option for it is a third-party application (gherkin-testcafe).
gherkin-testcafe illustrates the provision of tags without assignment operator, so I tried that one, too:
The
@
character still ends up escaped.I've also tried using
{*}
on invoking concurrently. So, the script in package.json is now:Invoking as before prevents the escaping, but yields a different issue:
So, the
{*}
seems to wrap all additional arguments in a single pair quotes. This may be intentional, but it definitely doesn't help here:The text was updated successfully, but these errors were encountered: