Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
When PuTTY loads a saved session, it will under some circumstances automatically launch it if it's launchable. "Launchable" used to simply mean that it actually specified a host name to connect to, but due to the serial port backend it's now a more complex criterion.
The original intention of the PuTTY configuration storage was that "Default Settings" should never describe a session which is launchable, which is why we don't permit a host name to be saved in the default settings. (People occasionally complain about this.)
However, due to an oversight, it is now possible to have Default Settings describe a launchable session: simply set "Protocol" to "Serial", and have the "Serial line" box non-blank (as it is by default). This leads to undesirable behaviour; in particular, PuTTY launched with no arguments will try to start up a session instead of bringing up the configuration dialog.
I'm not sure how best to fix this. Restricting what can be stored in Default Settings so that even serial-based defaults are forced not to be launchable seems to me like the wrong answer. Perhaps the right answer is actually to go through the code and ensure that Default Settings in particular is never automatically launched even if launchable. If we do that, then perhaps we could also repeal the restriction on having a default host name saved in Default Settings.
SGT, 2007-02-10: Should now be fixed, by the method described
above: Default Settings may describe a launchable session but is
never actually launched unless PuTTY is sure the user really meant
it. In particular, merely starting PuTTY doesn't launch the session
described by DS, and neither does double-clicking DS from the saved
sessions menu. Hitting Open once you've loaded it still works, and
using "-load
" still works. Also, as mentioned above,
I've relaxed the restriction on storing a host name in DS, on the
basis that since one type of launchable session is now permitted in
DS there's no reason not to permit the other too.
If you get into this situation, and can't upgrade permanently to 0.60 or later, the following workarounds are available:
Audit trail for this bug.