No check on first command line argument being an option
All GROMACS programs do not check if the first argument after the binary name starts with a dash. Any non-dash arguments are ignored until one with a dash is encountered.
This is especially an issue when cut-and-pasting from PDFs where all arguments can be ignored.
Handle erroneous command line args better
Some gmx modules need to be able to accept non-option arguments, and
some should not. Introduced enough functionality to support such
behaviour, while giving useful error messages in cases where the
command line is merely missing hyphens (which can happen e.g. when
people copy-paste from inconveniently built PDF files for tutorials).
Increased test coverage of relevant cases.
Removed some useless command-line argument strings from test cases
that never needed them.
Also tested some behaviours of handling string options, and renamed
some test input strings to reflect the intent.
#2 Updated by Szilárd Páll over 3 years ago
Looks like the change pushed up 2 months ago won't work, a rebase/retrigger reminded me that the unit tests also rely on this bug-feature, so there will have to be a whitelisting special-case for those or some other solution to address the invalid 1st argument case.
#7 Updated by Mark Abraham about 3 years ago
Things that still have to work appropriately after the fix:
gmx xyz gmx help trjconv gmx help xyz gmx -hidden help mdrun gmx -hidden mdrun -h gmx mdrun -h -hidden gmx tune_pme -ntomp 3 gmx -nocopyright grompp
Things that didn't work (well enough):
gmx grompp f gmx grompp f -c file.gro gmx grompp -c file.gro f
The third one is still not fixed by the change I will upload shortly - there's currently no way for the parser to find out whether an option has seen enough values.
Berk, did I cover the cases we saw during that tutorial at KTH?