What to do with 3 or more dashes #7

Activity

1. ljharb commented on Apr 30, 2021

   

   ljharb

   on Apr 30, 2021

   Member

   More actions

   I would expect ---foo to be the flag "-foo", or an error - ie, the third dash shouldn't change how things are parsed.

   👍React with 👍4Reacted by Joe Sepi, TED Vortex (Teodor-Eugen Duțulescu), Darcy Clarke and John Gee
2. joesepi commented on May 14, 2021

   

   joesepi

   on May 14, 2021

   CollaboratorAuthor

   More actions

   If we want to avoid throwing errors, should we simply warn or info on such a case where more than 2 dashes are used?
3. ljharb commented on May 14, 2021

   

   ljharb

   on May 14, 2021

   Member

   More actions

   Do we want that?
4. darcyclarke commented on Oct 27, 2021

   

   darcyclarke

   on Oct 27, 2021

   Member

   More actions

   @joesepi I don't think we want that & this question seems to have now been asked/answered in the FAQs section (ref. https://github.com/pkgjs/parseargs#faqs), re.

   • Is ---foo the same as --foo?
     • no
     • the first flag would be parsed as '-foo'
     • the second flag would be parsed as 'foo'

   The idea is that we keep a limited set of assumptions about names & values (ie. - is the prefix for shorthands & -- is the prefix for a flag... that's about it... no other validation). Notably, and something we should probably document, is that you can't ever make an alias/shorthand of "-" (as -- is a known/special identifier). Based on the current design though, we would interpret --- as if "-" is a flag name (ex. { args: { "-": true } ... } ~ which might be odd but is at least codified).

   Throwing an error or even warning when we see --- would mean we're assuming the input is incorrect. I think, as a rule, we should always successfully parse all input without warning/error. Special cases/exception handling can be left to tooling authors that want to build off of this more primitive implementation.

   Ex. of a simple two-liner someone could use to handle/warn of cases where --- is found...

   // cli.js ---foo
   const { parseArgs } = require('util')
   const { args } = parseArgs()
   
   // check for dashes & warn
   const errs = Object.keys(args).filter(name => name.startsWith('-'))
   if (errs.length) console.error(`Arguments passed beginning with dashes`) // ! Arguments passed beginning with dashes
5. darcyclarke

   added

   questionFurther information is requestedFurther information is requested

   on Oct 27, 2021
6. shadowspawn

   added a commit that references this issue on Dec 4, 2021

   Do not strip excess leading dashes on long option names

   ...

   7cc2ec7
7. shadowspawn commented on Dec 22, 2021

   

   shadowspawn

   on Dec 22, 2021

   Collaborator

   More actions

   Closed by #21
8. shadowspawn

   closed this as completedon Dec 22, 2021