nothing before -- should appear in ARGS

[rened]

I find the current behavior of command line argument parsing a bit in-consistent:

> julia -e "@show ARGS; using Watcher" -- julia RUN.jl
ARGS = UTF8String["julia","RUN.jl"]

> julia -e "@show ARGS; using Watcher" -now -- julia RUN.jl
ARGS = UTF8String["@show ARGS; using Watcher","-now","julia","RUN.jl"]

It seems that, as -- is optional, unknown parameters (like the -now) end up in ARGS despite them being before the --. That "@show ARGS..." ends up in ARGS is a bug IMHO.

To simplify the situation, I would like to propose to make the -- compulsory, i.e. nothing before -- can ever appear in ARGS.

[jakebolewski]

No, -- will never be compulsory. This is just wrong behavior.

[rened]

Ok, but would you agree that in case -- is present, nothing before -- should appear in ARGS?

[jakebolewski]

Yes.

[rened]

Ok, I'll try to track this down then and submit a PR.

[jakebolewski]

Cool. The relevant code is in client.jl in process_options. ARGS should be assigned a copy of all string arguments after the -- delimiter. Right now it is just getting removed.

[rened]

Thanks for the lead!

[jakebolewski]

@rened if you are feeling ambitious, you could implement the behavior described here #10726 (comment). Although I suspect the one who implements the "correct" behavior will be the only one to actually use it.

[rened]

@jakebolewski excellent, I also wanted to suggest to allow multiple --s. Will do.

[vtjnash]

To simplify the situation, I would like to propose to make the -- compulsory, i.e. nothing before -- can ever appear in ARGS.

that would not be standard unix behavior – argument parsing is expected to end on -- or the first unrecognized argument.

i agree that the disappearance of the -- from the ARGS list might be considered a bug (this is caused by the leading + to the getopt_long options string) as well as the inclusion of the argument string to -e in ARGS (it looks like the -n -o -w argument is confusing argument counting, possibly related to the leading character being + in the options string?)

for anyone who's investigating this further, I also discovered:

$ ./julia --compile=yes -foo
julia: unknown option `--compile=yes`

where the unknown option was -foo, not --compile