You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is unexpected result. Why does the argument value "foo" set the hflag to true and file is still null?
I intuitively thought that the results would have been: pflag = true, hflag = false, jflag = false, file = "foo" but for some reason this was not the case.
This is also unexpected result. Why does the argument values "foo" and "bar" set the hflag and jflag to true?
I intuitively thought that this command line would have been rejected because there were 2 string arguments "foo" and "bar".
This is again unexpected result. Why does the argument values "foo" and "bar" set the hflag and jflag to true?
I intuitively thought that this command line would have been rejected because there were 3 string arguments "foo", "bar" and "baf".
jk@t04:~/bin$ expmainargs.sc template -p foo bar baf blaa
2023-04-08_23:29:18.136 [main] DEBUG e.sc - Using logback config: /home/jk/bin/logback.xml
Unknown argument: "blaa"
Expected Signature: template
Print stuff into file.
-p --pflag This is p-flag.
-h --hflag This is h-flag.
-j --jflag This is j-flag.
-f --file <str> Output file name.
This is expected result, too many arguments.
Is this an error in mainargs code or something missing from the user documentation or what is the problem?
Used versions:
mainargs:0.4.0
scala -version
Scala code runner version 2.12.8 -- Copyright 2002-2018, LAMP/EPFL and Lightbend, Inc.
java -version
openjdk version "11.0.18" 2023-01-17
OpenJDK Runtime Environment (build 11.0.18+10-post-Ubuntu-0ubuntu120.04.1)
OpenJDK 64-Bit Server VM (build 11.0.18+10-post-Ubuntu-0ubuntu120.04.1, mixed mode, sharing)
amm
Loading...
Welcome to the Ammonite Repl 2.4.0 (Scala 2.12.13 Java 11.0.18)
Thank you for your support!
The text was updated successfully, but these errors were encountered:
Can you minimize this further? If this is a mainargs issue, I'd like a repro without dozens of lines of irrelevant logback initialization code and file io handling
…#66)
Should fix#58 and
#60
Previously, we allowed any arg to take positional arguments if
`allowPositional = true` (which is the case for Ammonite and Mill
user-defined entrypoints.), even `mainargs.Flag`s. for which being
positional doesn't make sense.
```scala
val positionalArgSigs = argSigs
.filter {
case x: ArgSig.Simple[_, _] if x.reader.noTokens => false
case x: ArgSig.Simple[_, _] if x.positional => true
case x => allowPositional
}
```
The relevant code path was rewritten in
#62, but the buggy behavior
was preserved before and after that change. This wasn't caught in other
uses of `mainargs.Flag`, e.g. for Ammonite/Mill's own flags, because
those did not set `allowPositional=true`
This PR tweaks `TokenGrouping.groupArgs` to be more discerning about how
it selects positional, keyword, and missing arguments:
1. Now, only `TokenReader.Simple[_]`s with `.positional` or
`allowPositional` can be positional; `Flag`s, `Leftover`, etc. cannot
2. Keyword arguments are limited only to `Flag`s and `Simple` with
`!a.positional`
Added `mainargs.IssueTests.issue60` as a regression test, that fails on
main and passes on this PR. Existing tests all pass
I have simple experimental scala script using
mainargs
.When I run this with different arguments I got following results:
This is expected result.
This is expected result.
This is unexpected result. Why does the argument value
"foo"
set thehflag
totrue
andfile
is stillnull
?I intuitively thought that the results would have been:
pflag = true
,hflag = false
,jflag = false
,file = "foo"
but for some reason this was not the case.This is also unexpected result. Why does the argument values
"foo"
and"bar"
set thehflag
andjflag
totrue
?I intuitively thought that this command line would have been rejected because there were 2 string arguments
"foo"
and"bar"
.This is again unexpected result. Why does the argument values
"foo"
and"bar"
set thehflag
andjflag
totrue
?I intuitively thought that this command line would have been rejected because there were 3 string arguments
"foo"
,"bar"
and"baf"
.This is expected result, too many arguments.
Is this an error in
mainargs
code or something missing from the user documentation or what is the problem?Used versions:
Thank you for your support!
The text was updated successfully, but these errors were encountered: