fix: wrap unknown args in quotes

[jly36963]

Addresses:
#2033

Problem

If an unknown argument is only whitespace, it causes confusing output: Unknown argument:

Reproduction

Code

// multiline.js

const yargs = require('yargs')

yargs(process.argv.slice(2))
  .command(
    '$0',
    'default description',
    yargs => yargs
      .option('opt1', { type: 'string' })
      .option('opt2', { type: 'string' }),
    argv => {
      console.log(argv)
    }
  )
  .strict()
  .parse()

# multiline.sh (version 1)

# space after backslash on opt1 line
node multiline.js \
--opt1=hello \   
--opt2=world

# multiline.sh (version 2)

# no space after last baskslash on opt1 line
node multiline.js \
--opt1=hello \   \
--opt2=world

Explanation

Calling multiline.js from multiline.sh (version 1) will result in an error like command not found. This makes sense, as having a space between the backslash and newline will prevent the newline from being escaped, and the newline would cause the next line to be interpreted as a new command.

Calling multiline.js from multiline.sh (version 2) will result in the unknown argument: error. I added a .map() call to the unknown arguments that will wrap them in quotes. This will make the error described in the issue a bit easier to understand: Unknown argument: " "

I don't know what might cause the situation in version 2. The issue specifically mentioned the error happening in a multiline run: | command in github actions. Maybe there's some process (like something in the github actions runner) that adds backslashes (where missing) at the end of each line within a multiline command. If something like this is happening, then extra backslashes would be added to the end of lines with trailing whitespace. I only have suspicions, and I feel like investigating it is outside the scope of this fix.

Solution

The solution mentioned in the comments section of the issue was to wrap arguments listed in the usage output in quotes, rather than trimming/mutating the elements of argv.

Questions

For the usage output:

• Should I wrap all unknown arguments in quotes? Only whitespace ones?
• Should I modify all similar usage output to also use quotes? (missing required argument: %s, etc)

[bcoe]

@jly36963 If I'm understanding correclty, the problem is the form:

foo \[space]
--bar\
--final

And this would work?

foo \
--bar\
--final

I like your approach of making this jump out better to people.

[jly36963]

@bcoe

This causes the shell to throw command not found error, before the yargs program is run.

# newline is NOT escaped, --bar is interpreted as new command
foo \[space]
--bar\
--final

This causes yargs to throw unknown argument: error.

# newline is escaped, space is interpreted as an argument
foo \[space]\
--bar\
--final

(I think the second scenario would only happen if there is some process (before execution) adding backslashes at the end of lines that don't have them.)

[bcoe]

I say ship it 👌this will at least help people identify this odd edge case.

[jly36963]

@bcoe
To be consistent with different kinds of error messages, should I modify all similar usage output to also use quotes? (missing required argument: %s, etc)

It wouldn't take very long

[bcoe]

@jly36963 sounds like consistentcy would be worthwhile, did you want to do so in this PR, or merge this PR and have some follow up work?

[jly36963]

@bcoe
I can definitely do it in this PR, it should go pretty quick

[jly36963]

@bcoe
I'm happy with where it's at now. I took the minimalist approach: If an argument is just whitespace, it's wrapped in quotes; otherwise, it's left alone. I only did it for arguments, because I don't think there is a way to make ' ' an unknown command.