Handle unrecognized cli arguments #1199
Conversation
| @@ -87,7 +87,7 @@ export default function denoMain() { | |||
| log("cwd", cwd); | |||
|
|
|||
| // TODO handle shebang. | |||
| for (let i = 1; i < startResMsg.argvLength(); i++) { | |||
| for (let i = 0; i < startResMsg.argvLength(); i++) { | |||
There was a problem hiding this comment.
This is intentional. I believe it serves the same purpose as your let args = env::args().skip(1).collect(); line below
| // in userland) | ||
| // deno --allow-env foo.ts --foo=bar | ||
| // parsing will stop when `foo.ts` is encountered | ||
| opts.parsing_style(ParsingStyle::StopAtFirstFree); |
There was a problem hiding this comment.
Hrm.. I'd rather not StopAtFirstFree. It would be nice to intermix flags from core and user programs.
There was a problem hiding this comment.
Maybe you can show a test case of what's going wrong?
There was a problem hiding this comment.
Apologies if I'm way out of line here since I'm just starting to get involved with deno and I might be misreading this comment.
Wouldn't intermixing flags from core and user programs cause problems down the line?
It looks like a clear separation is the only way to defend programs (and core) from potential issues that might arise from arguments being added / removed, and would avoid confusion?
example: deno program.ts --version is this passing --version to program? or to deno? both?
example2: deno program.ts --some-arg initially --some-arg is not a deno argument, but down the line, it's aded to deno, would the program stop working?
or did I get it wrong?
|
Let's continue in #1200 |
This PR tries to fix #1198.