Consistent behavior with missing or incorrect arguments

[Rangi42]

Fixes #1131
Fixes #1132

• Running rgbasm, rgblink, rgbgfx, or rgbfix with an incorrect argument (e.g. --foobar) will give an "unrecognized option" error, show the usage information, and exit.
• Running rgbasm, rgblink, rgbgfx, or rgbfix without any arguments will give a fatal error, show the usage information, and exit.

Previously, running rgbfix without any arguments would default to processing - (stdin). Now you need to explicitly pass -.

[ISSOtm]

What good is rgbfix useful for without any arguments?

It may be worth aligning its behaviour with the other three, and mentioning "use rgbfix - if you want to simply pipe the input" or something.

[Rangi42]

What good is rgbfix useful for without any arguments?

It may be worth aligning its behaviour with the other three, and mentioning "use rgbfix - if you want to simply pipe the input" or something.

I didn't want to accidentally break someone's workflow who's using < foo.asm rgbasm -o - - | rgblink -o - - | rgbfix > foo.gb instead of | rgbfix -. But yeah, if it's okay to break that negligible possibility, I'd rather have them be consistent.

[ISSOtm]

Well, it's unlikely enough, we've had several reports of people being confused by RGBFIX's behaviour (appearing to hang), and we're not WG14, so I think it's worth breaking.

We'll have to add a note in the changelog to highlight the breakage as intentional for future reference, I guess.

[pinobatch]

A couple years ago, I wrote a compression tool in C to avoid a Python dependency in a replacement boot ROM. I checked whether isatty(fileno(stdout)) before trying to compress to standard output and whether isatty(fileno(stdin)) before trying to decompress from standard input. The user would get an error like this:

pb8: cannot compress to terminal; try redirecting stdout or pb8 --help

I had to do a bit of #ifdef at the top to make it work on both POSIX and Windows systems.

[aaaaaa123456789]

Just break this; the fix is easy. But please do mention it, so people know how to fix this.

[Rangi42]

Done: rgbfix is now consistent with the rest, and man pages explicitly mention -.

[Rangi42]

I didn't want to accidentally break someone's workflow ...

Well, it's unlikely enough, we've had several reports of people being confused by RGBFIX's behaviour (appearing to hang), and we're not WG14, so I think it's worth breaking.

Just break this; the fix is easy. But please do mention it, so people know how to fix this.

Of course, the rgbfix tests themselves depended on this, and now they're all breaking. :P (Edit: should be fixed now.)

[ISSOtm]

What's the rationale for making all of the "print usage" functions "noreturn"? It feels like it's obscuring the control flow IMO.

[Rangi42]

What's the rationale for making all of the "print usage" functions "noreturn"? It feels like it's obscuring the control flow IMO.

Some of them already called exit() inside, and the ones that didn't were always immediately followed by exit() anyway. Would it help to rename them all exitUsage?

[aaaaaa123456789]

I'd say this is pretty standard, because if you're printing usage information, you're not doing anything else. I've never seen a program print usage information and not exit right after.
Exiting from inside those functions is quite common, too.

[ISSOtm]

It would make sense to print an extra line afterwards, for example. I'd rather have the flow control be explicit in the caller.

[Rangi42]

It would make sense to print an extra line afterwards, for example. I'd rather have the flow control be explicit in the caller.

Okay.

[ISSOtm]

Great! The UX should improve that much overall. Thank you!

Resolved