2

In documentation there is info about additional streams besides standard stdin, stdout and stderr. ( http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true )

UNDEFINED 3-9 - These handles are defined individually by the application and are specific to each tool.

So what I want to accomplish is to create by own output stream let's say on slot 3 and use it for debug. (I see there is no stddbg stream provided by the system.)

So my question is - Is it possible to check that a nonstandard output stream is waiting for data, like I do with stderr:

isatty(fileno(stderr)) == 0

And then I have option to choose a different kind of error information format more friendly to log file. The code above is true when using command in this way:

myApp.exe param1 param2 2> error.log

but when I need to differentiate between debug (or performance) and error messages it's tempting to use another stream like:

myApp.exe param1 param2 3> debug.log

but how do I check that this stream is connected to the application, what name should I use as parameter to the fileno() function ?

rsk82
  • 28,217
  • 50
  • 150
  • 240

2 Answers2

2

Handles 3-9 seem to be just additional temporary handles for playing with command line, for example for buffering some input/output. Look for some dos shell sorcerers' answers, for example this or this, to see how to use it. I don't think you can define it programatically.

Community
  • 1
  • 1
Bogdan
  • 984
  • 8
  • 16
2

Sadly, the custom streams only exist within a particular instance of cmd.exe and are not passed to subprocesses. (Even child cmd.exe processes don't inherit the custom streams from the parent.)

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
  • so the ms documentation is blatantly lying suggesting that these streams are programatically accessible: `specific to each tool`, wow. – rsk82 May 14 '14 at 00:07
  • 2
    Technically, they are programmatically accessible, but only to MS developers working on the built-in commands. I suspect whoever wrote that document was either never aware of that limitation or didn't understand it. Unfortunately, in my experience, the world is rather short on people who can both understand this sort of technical detail and can write about it clearly - many people can do one or the other, but few can do both. :-) – Harry Johnston May 14 '14 at 00:17