mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-03-13 02:23:50 -05:00
e230751853
Originally, it controlled whether ssh.c should send terminal messages (such as login and password prompts) to terminal.c or to stderr. But we've had the from_backend() abstraction for ages now, which even has an existing flag to indicate that the data is stderr rather than stdout data; applications which set FLAG_STDERR are precisely those that link against uxcons or wincons, so from_backend will do the expected thing anyway with data sent to it with that flag set. So there's no reason ssh.c can't just unconditionally pass everything through that, and remove the special case. FLAG_STDERR was also used by winproxy and uxproxy to decide whether to capture standard error from a local proxy command, or whether to let the proxy command send its diagnostics directly to the usual standard error. On reflection, I think it's better to unconditionally capture the proxy's stderr, for three reasons. Firstly, it means proxy diagnostics are prefixed with 'proxy:' so that you can tell them apart from any other stderr spew (which used to be particularly confusing if both the main application and the proxy command were instances of Plink); secondly, proxy diagnostics are now reliably copied to packet log files along with all the other Event Log entries, even by command-line tools; and thirdly, this means the option to suppress proxy command diagnostics after the main session starts will actually _work_ in the command-line tools, which it previously couldn't. A more minor structure change is that copying of Event Log messages to stderr in verbose mode is now done by wincons/uxcons, instead of centrally in logging.c (since logging.c can now no longer check FLAG_STDERR to decide whether to do it). The total amount of code to do this is considerably smaller than the defensive-sounding comment in logevent.c explaining why I did it the other way instead :-)