Fix #113: Allow positional arguments after optional arguments

[ahpooch]

Description

This PR fixes issue #113 where pykms_Client.py fails to parse command line arguments correctly when positional arguments are placed after optional arguments.

Problem

The kms_parser_check_optionals() function in pykms_Misc.py was incorrectly validating command-line arguments. When a positional argument (like an IP address) appeared after an optional argument (like -m Windows10), the parser would treat it as an unknown option and raise an error.

Example of the bug:

$ python3 pykms_Client.py -m Windows10 192.168.10.1
optional py-kms client argument `-m`: expected one argument, unrecognized: '192.168.10.1'. Exiting...

$ python3 pykms_Client.py -y 192.168.10.1
optional py-kms client argument `-y`: expected zero arguments, unrecognized: '192.168.10.1'. Exiting...

This happened because the validation logic checked if the element following an option was a known optional argument, and if not, raised an error - without considering that it might be a legitimate positional argument.

Solution

Modified the validation logic in pykms_Misc.py (line 430) to only raise an error for unrecognized optional arguments (those starting with -), while allowing positional arguments to pass through.

Change made:

# Before:
if elem and elem not in allarg:
    raise KmsParserException(...)

# After:
if elem and elem.startswith('-') and elem not in allarg:
    raise KmsParserException(...)

This simple change ensures that:

1. Unknown options (starting with -) are still caught and reported as errors
2. Positional arguments (not starting with -) are allowed after optional arguments
3. Argument order flexibility is maintained

Testing

After the fix, all the following commands work correctly:

✅ With positional arguments after optional arguments:

python3 pykms_Client.py -m Windows10 192.168.10.1
python3 pykms_Client.py -y 192.168.10.1
python3 pykms_Client.py -m Windows10 192.168.10.1 1688
python3 pykms_Client.py -F STDOUT -m Windows10 192.168.10.1

✅ Traditional order (positional before optional) still works:

python3 pykms_Client.py 192.168.10.1 -m Windows10
python3 pykms_Client.py 192.168.10.1 1688 -m Windows10

✅ Error handling for invalid options still works:

$ python3 pykms_Client.py -m InvalidMode 192.168.10.1
argument -m/--mode: invalid choice: 'InvalidMode' (choose from ...). Exiting...

Impact

• Changed files: 1 (py-kms/pykms_Misc.py)
• Lines changed: 1 line modified
• Breaking changes: None - this is a pure bug fix that adds functionality
• Backward compatibility: Fully maintained - all existing valid command-line patterns continue to work

Related Issues

Fixes #113

Checklist

• The code has been tested locally
• The fix is minimal and focused
• No breaking changes introduced
• Existing functionality is preserved
• The commit message follows the project conventions

[Copilot]

Pull request overview

This PR addresses issue #113 by adjusting optional-argument validation so positional arguments placed after optionals (e.g., -m Windows10 192.168.10.1) are not incorrectly rejected as “unrecognized options”.

Changes:

• Updated kms_parser_check_optionals() length-validation to only raise on unrecognized tokens that look like option flags (start with -), allowing subsequent positional args.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[simonmicro]

How about the @ahpooch moves the if elem into a new else: section of the try-except and we remove the elem declaration to None from the top?