Combining Command Line Arguments Fails

[David (PassMark)]

Glad you sorted it out.

I think it is normal that "/smemory" is not the same as "/s memory".

It is the same as the common Linux command "ls -ls*" not being the same as "ls -l s*". Isn't it?

[wamorita]

In trying to specify "/s <script_name>" and "/r" on the same command line call to bit.exe, the "/r" seem to be always ignored whether it precedes or trails the script specification.
It would appear that to load a script and execute it requires two calls to bit.exe.

Examples:

bit.exe /r /s memory # This fails to start the memory test

bit.exe /s memory
bit.exe /r # This forces execution of the currently loaded configuration, not limited to memory

Being able to load a script file specified on the command line is relatively useless unless you can get it to execute.

Note: Rebooting does not seem to help.

Is there a setting someplace that suppresses the "/r" in conjunction with other options?

Additionally further testing has yielded weakness in the parsing of the command line options.
"/smemory" is not the same as "/s memory". The documentation is not clear on this and a person familiar to Unix/Linux would assume they are equivalent.

==============================
Solved issue:
"/s memory" and "/s memory.bits" are not equivalent
If ".bits" is not present, the script is processed to the point of only selecting the "memory" tests.
If ".bits" is present, execution proceeds as expected.