Automatically remap any configured stderr, stdout, stdin streams

[mcandre]

As a newbie, I want cloudabi-run to automatically look for any keys named stderr, stdout, or stdin in the CloudABI configuration and remap such streams to the new file descriptors, such as with dup2(). So that our users can conveniently continue to access assert(), printf(), etc., without having to write custom logic to set this up for each application.

Okay, I see that cloudlibc provides dup2(), however this is not particularly useful for remapping stderr and friends, without also defining STDERR_FILENO, STDOUT_FILENO, and STDIN_FILENO. Could we declare these like -2, -3, -4, so that we can refer to them for remapping?

[EdSchouten]

Keep in mind that this can already be achieved in the form of a library, wrapper, etc. The traditional POSIX runtime environment could be modeled by having a YAML schema like this:

args:
- ls
- -l
envs:
  HOME: /home/ed
  PATH: /bin:/sbin:/usr/bin:/usr/sbin
stdin: !fd ...
stdout: !fd ...
stderr: !fd ...
working_directory: !fd ...
network: !flower_switchboard_handle ...

And then you could write a wrapper library that:

• provides a copy of all of the functions that are missing in cloudlibc (e.g., a regular open(), socket(), bind(), connect()),
• declares stdin and stdout,
• calls functions like fswap() to set up stderr,
• calls into a traditional main() function.

The nice thing about putting it in a separate library is that it makes it easier for people to opt in/opt out of this kind of functionality. People who want to have a pure capability-based programming environment could use CloudABI as is. People who just want get an existing application to build without a lot of hassle can use the compat layer described above.

It's important to mention that even though I'd applaud the development of such a compat layer, I'd rather not have it part of the CloudABI project itself (e.g., part of the cloudlibc repository). If using such a layer would become the norm, we wouldn't gain anything in the end.