Supports for shell script string? about string-argv HOT 6 CLOSED

I think what he's looking for is recognition of the shell subcommand $(git ls-files) as a single parameter. I feel like this is beyond the scope of what this module is supposed to do.

from string-argv.

Just to be clear, is this the expected result you would want?

stringArgv('eslint `git ls-files`') === ["eslint", "git ls-files"]
stringArgv('eslint $(git ls-files)') === ["eslint", "git ls-files"]

This would need to be able to give custom start/end markers for arguments.
Unfortunately, I don't know how to implement the $( marker with a Regex since it has 2 characters.

It would be possible to parse the string manually instead of using a regex (essentially building a state machine myself).

I'll consider it if I can find some time to play around with it.

from string-argv.

is this the expected result you would want?

No.

expected result:

stringArgv('eslint `git ls-files`') === ["eslint", ["git", "ls-files"]]
stringArgv('eslint $(git ls-files)') === ["eslint", ["git", "ls-files"]]

or

stringArgv('eslint `git ls-files`') === ["eslint", "`git ls-files`"]
stringArgv('eslint $(git ls-files)') === ["eslint", "$(git ls-files)"]

See: https://www.gnu.org/software/bash/manual/html_node/Command-Substitution.html

from string-argv.

None of those expected results follow the current logic of argument parsing string-argv supports.
What are you trying to achieve exactly ?

If you have control over the input, you could do the following with the current implementation.

stringArgv('eslint "`git ls-files`"') === ["eslint", "`git ls-files`"]
stringArgv('eslint "$(git ls-files)"') === ["eslint", "$(git ls-files)"]

from string-argv.

What are you trying to achieve exactly ?What are you trying to achieve exactly ?

I was try to supports shell script for windows.

from string-argv.

In order to support this, I would have to allow custom start/end tokens for "quoted" values.
Right now the module only supports single and double quotes.
Adding support for custom start/end tokens (especially tokens with more than 1 character) would require a big revamp of the parsing logic of this module.
I feel it would add a lot of complexity for a module I am trying to keep as simple as possible.

For these reasons, I will not add support for this use-case

from string-argv.