Is this a bug or a deliberate design decision to break with OS3/MorphOS behaviour considering the
interpretation of a 0 filehandle for SYS_Output?
SYS_Output has not changed, SYS_Input has, and just by using ZERO for SYS_Input in your example means that
you do not understand the ramifications. There is no documentation to say that ZERO can be used here,
this is exactly the reason why passing a ZERO SYS_Input tag now causes System() to open "NIL:" by default.
This is required to fix a bunch of issues with older applications using ancient startup code,
or programs that didn't always check for invalid streams and went on to access invalid memory addresses,
at the same time, it provides a consistent and safer behaviour for 68K and PPC programs that doesn't end
in a crash or memory trashing if the user was unaware of the ramifications.
System() used a ZERO SYS_Output argument as a local switch to make a copy of the input stream even in OS3.xx,
which means you always needed to have a valid input stream, via SYS_Input, or inherited from the parent.
The result of this usually ended up in the new process structure in ->pr_CIS ie: Input().
ZERO is not a valid filehandle and is (mis)interpreted differently everywhere the input or output stream
was used and sometimes coders didn't even considered ZERO to be a possibility.
Here's a list of things that immediately come to mind when passing an input filehandle of ZERO,
these are clipped directly from the various autodocs....
* Before 53.65 launching asynch commands from a workbench started process
* that use clib/newlib wrappers would initialise their own pr_ConsolePort
* and close it when that process ends, if an ASYNCH child shell process
* was started with the SYS_Input tag set to ZERO, it would copy the
* parents pr_ConsolePort which would leave the new ASYNCH child process
* using a dead pr_ConsolePort when the parent process exits.
* So now, specifying a ZERO input stream automatically opens "NIL:"
* no matter what mode is used.
* If an Input() stream of zero is supplied, the argument string in
* the input filehandle feature will not be available to the command.
* This means that ReadArgs() and other parsers will not work, ...
There are more issues like this scattered around all over the place, these are now safe in OS4,
but previous OS versions and possibly other flavours of AmigaOS may not have discovered
these issues, how they respond is unknown.