Found an issue and fixed it. Turns out destroying my #Process instance when the child exited was wrong, there could still be unread data in the #pipe. But then, only waiting for #EOF on the pipe was equally wrong ...

Now the code does the only reliable thing:

* When the child terminated, close the pipe for stdin immediately if one was present
* Only destroy the process instance once the child terminated AND the pipes for #stdout and #stderr (IF they were present) found EOF.

Committed now:
https://github.com/Zirias/poser/commit/18051d9da0ba7e4caf2882828e5706e35d419f94

And here are the docs:
https://zirias.github.io/poser/api/latest/class_p_s_c___process.html

My testing code also had to change a bit and now makes for a completely pointless and cute wrapper around /bin/ls

@b0rk

has a neat way to demonstrate; 2&>1

this has always been a tricky thing to explain to folks new to the shell

#shell
#stderr
#stdout
#pipes
#redirects

@rk @cks

I was going to ask how many system calls it was making. If the Go runtime library is choosing no buffering when the standard output is the null device, that could be a lot of syscalls, compared to full buffering.

How is the Go runtime library deciding what buffering policy to use for standard streams? Is it even using buffers for standard streams? Does it vary that decision for character and TTY devices?

Now remember - so far all of this is just to get two lists - my TableOfContents and all of the WikiWords that exist in my file.

If you use #Linux or #Unix for any period of time (or #GnuLinux - where my pedants at?), you will probably have come across `sort`.

Now we get to talk about streams and files!

Everything in Linux is a file. Which is shockingly powerful. Input from the keyboard? A file you can read from. Output to the screen? A file you can write to. #stdin and #stdout are their names