I'm not sure why do we call close(0..2) for std files when
the apr_file_open_std* is closed or it's pool destroyed at the
first place.
Reading the:
* @remark The only reason that the apr_file_open_std* functions exist
* is that you may not always have a stderr/out/in on Windows. This
* is generally a problem with newer versions of Windows and services.
So apr_file_open_std* should just reference the existing
system descriptors. However it behaves like 'attach' rather then open,
meaning once you open it you will destroy the system stdin/stdout/stderr.
Thus by design it's a singleton operation, so if desired,
the second invocation during the process lifetime should always
return EBADF for apr_file_open_std* thought.
Very confusing.
This is related with another my problem. If I close stdout by
apr_file_close, then the standard printf and fprintf(stdout, ) functions
are no more working.
I've tested this on Windows and Linux.
Regards,
Yura