Open rotanov opened 9 years ago
I was wrong about "nul" getting it's way to the CreateFile.
what's really going on is options.cpp:109-111
if (name == CLEAR_STRING) {
stdoutput.clear();
return;
}
where CLEAR_STRING is:
// TODO: use c_list /dev/null || nul system dependent
const std::string CLEAR_STRING = "nul";
So no buffer is created and nul
is not passed to CreateFile. Though printf
calls block if stdout is redirected to pipe and no one consuming the pipe when internal pipe buffer fills up. (tested) So now we must hold a separate thread for each stdout, stderr just to consume it so it won't block. It would be neat to make it without a thread.
So, concluding the research --out=nul is intended not to redirect stdout to null device but to clear all previous --out=<...> arguments. Which is obscure.
In order to void stdin or stdout of a program we do:
sp.exe --out=nul ...
orsp.exe --in=nul
(I highly doubt the latter will work as intended though but the first one is actually used)The thing is "nul" or "nul:" is a predefined name for null device in Windows which is "/dev/null" in GNU/Linux. It happens to be passed as a filename to CreateFile WinAPI and everything seem to behave fine.
It needs to be clarified though what we want to achieve and what's really going on now.