I only have a week left to my internship, so I'm going to add Jason to take this over in case it doesn't get dealt with in the next week.

Basically, the issue is that it's difficult to tell the difference between a command that failed and a command that isn't supported. In this situation, minnie is listed as supporting all platform commands because there isn't a way to list supporting only some. When you try to execute the ones that aren't implemented, mosys returns with an error. From the command line side, this is identical to a command failing because of an application error.

My internship is ending, so I'm going to assign this to Alec.

Technically speaking, I think that "Command not supported on this platform" was a lie because Mosys had no way of actually knowing that: all it knows is that the command failed to execute.

Oooo I like that! From now on all my code shall read:

try {
  whoKnowsWhatThisWillDo();
} catch() {
  console.log('Command not supported on this platform');
}

Are you suggesting that mosys is working as intended then?

Sorry that was more of a general joke about errors in code, not specific to this bug Stephen. As Samantha said, it's difficult to tell in Mosys what is an error and what is an invalid command because of the way commands dispatch is handled.

I don't work on Mosys so I don't think I'm the right person to own this. We might also want to mark it wont-fix (the way Mosys is structured means this isn't obviously incorrect behaviour).

How hard is it to change mosys to understand the different between an unsupported command and a general application error?

At a minimum, can we change the error message to indicate that the error could be that the issued command is not supported?

I thought the code would have changed from when I last looked at it, but I still see the same dispatch code and C code (rather than rust).

I'm happy to do something here, but would like Jason to tell me what to do so I fit in with the future direction (and more importantly what not to do!)

Mosys is being transitioned to the Build team but I can still provide some guidance.

There's 3 issues here:
1. "Application error" is too aggressive as messaging
   for perfectly valid exit reasons
2. Subcommand returning a -1 shouldn't be reported to
   be command failure; it might be an unsupported command
3. Subcommands returning -1 for both unsupported and
   actual errors

Fixing (3) is a lot of work and one of the Mosys architectural issues that needs to be addressed but we probably don't have time for now.

Fixing (1) is super easy. Just change this one line: https://chromium.googlesource.com/chromiumos/platform/mosys/+/master/src/main.rs#61 . Probably, the best thing to do is to not prefix with anything at all because the err struct always has an clear message: https://chromium.googlesource.com/chromiumos/platform/mosys/+/master/src/lib.rs#408

Fixing (2) is a little harder. That's happening here: https://chromium.googlesource.com/chromiumos/platform/mosys/+/master/src/lib.rs#303 when the command returns anything other than 0. The old C code did this: https://chromium.googlesource.com/chromiumos/platform/mosys/+/d1ae3d1ff9aaf7ce38aa2055c26d2b58e4a9a50e/mosys.c#296 which was just print "Command not supported on this platform" when any kind of non-zero return from any command. This output isn't true because the root cause might be a real error, not a lack of platform support. An alternative message might be to just state the facts: "$COMMAND_NAME returned $RETURN_CODE" since we can't really editorialize about the reason.

over to Greg to see about shaking it out

From what I recall on doing some of the nautilus/soraka unibuild conversions is that one of the error messages was non-unibuild and the other unibuild. 

Mosys is going to go under heavy modifications once we get some better test scaffolding and safety nets in place.