mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-03-13 18:43:52 -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 :-)
PuTTY README
============
This is the README file for the PuTTY installer distribution. If
you're reading this, you've probably just run our installer and
installed PuTTY on your system.
What should I do next?
----------------------
If you want to use PuTTY to connect to other computers, or use PSFTP
to transfer files, you should just be able to run them from the
Start menu.
If you want to use the command-line-only file transfer utility PSCP,
you will probably want to put the PuTTY installation directory on
your PATH. On Windows 7 and similar versions, you can do this at
Control Panel > System and Security > System > Advanced system
settings > Environment Variables.
Some versions of Windows will refuse to run HTML Help files (.CHM)
if they are installed on a network drive. If you have installed
PuTTY on a network drive, you might want to check that the help file
works properly. If not, see http://support.microsoft.com/kb/896054
for information on how to solve this problem.
What do I do if it doesn't work?
--------------------------------
The PuTTY home web site is
https://www.chiark.greenend.org.uk/~sgtatham/putty/
Here you will find our list of known bugs and pending feature
requests. If your problem is not listed in there, or in the FAQ, or
in the manuals, read the Feedback page to find out how to report
bugs to us. PLEASE read the Feedback page carefully: it is there to
save you time as well as us. Do not send us one-line bug reports
telling us `it doesn't work'.