What happens
The dataize command derives its object name and program arguments directly from raw program.args (src/eoc.js:311-317: coms().dataize(program.args[1], program.args.slice(2), ...)). The command declares --stack and --heap options (src/eoc.js:304-305) but no .argument(), so commander leaves those option tokens sitting inside program.args instead of parsing them out, and the code indexes into that array blindly.
Verified with a fake java on PATH that echoes its argv:
$ node src/eoc.js --alone dataize --heap 1G foo
FAKE-JAVA-ARGS: ... -Xmx1G -jar .../eoc.jar --heap 1G foo
^ the object name became "--heap" instead of "foo"
$ node src/eoc.js --alone dataize foo --heap 1G
FAKE-JAVA-ARGS: ... -Xmx1G -jar .../eoc.jar foo --heap 1G
^ heap is correctly applied to the JVM, but "--heap 1G" also leaks into the
dataized program's own argv
$ node src/eoc.js --alone dataize ; echo rc=$?
FAKE-JAVA-ARGS: ... -jar .../eoc.jar
rc=0
^ no object name given at all: runs the jar with nothing and exits 0
So the natural CLI ordering eoc dataize --heap 1G myobject silently picks the wrong object name, the "correct" ordering (options first is what most CLI tools also get wrong the other way, but here even putting the object first still pollutes the target program's own arguments) leaks the option tokens into the dataized program's argv, and a missing object name is accepted without any error.
The same raw-program.args idiom also appears in src/commands/js/link.js:19 (program.args[0] === 'test') - it happens to be safe there today given the current option set, but it is the same fragile pattern and could break the same way if a new option is ever added to that command.
What should happen
dataize should declare its operands properly (e.g. .argument('<object>') and .argument('[args...]')) and use the values commander hands to the action callback, instead of reading program.args directly. That would make --heap/--stack position-independent, keep them out of the dataized program's own argv, and let commander itself report a clear error when the object name is missing.
What happens
The
dataizecommand derives its object name and program arguments directly from rawprogram.args(src/eoc.js:311-317:coms().dataize(program.args[1], program.args.slice(2), ...)). The command declares--stackand--heapoptions (src/eoc.js:304-305) but no.argument(), so commander leaves those option tokens sitting insideprogram.argsinstead of parsing them out, and the code indexes into that array blindly.Verified with a fake
javaon PATH that echoes its argv:So the natural CLI ordering
eoc dataize --heap 1G myobjectsilently picks the wrong object name, the "correct" ordering (options first is what most CLI tools also get wrong the other way, but here even putting the object first still pollutes the target program's own arguments) leaks the option tokens into the dataized program's argv, and a missing object name is accepted without any error.The same raw-
program.argsidiom also appears insrc/commands/js/link.js:19(program.args[0] === 'test') - it happens to be safe there today given the current option set, but it is the same fragile pattern and could break the same way if a new option is ever added to that command.What should happen
dataizeshould declare its operands properly (e.g..argument('<object>')and.argument('[args...]')) and use the values commander hands to the action callback, instead of readingprogram.argsdirectly. That would make--heap/--stackposition-independent, keep them out of the dataized program's own argv, and let commander itself report a clear error when the object name is missing.