This was a bit rushed, and could doubtless be improved.
Also fix a couple of things I noted on the way, including:
- "pscp -ls" wasn't documented
- Windows XP wasn't mentioned enough
[originally from svn r5593]
* All the PuTTY tools for Windows and Unix now contain the fingerprints of
the Master Keys. The method for accessing them is crude but universal:
a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes
"--pgpfp" just to be awkward.)
* Move the key policy discussion from putty-website/keys.html to
putty/doc/pgpkeys.but, and autogenerate the former from the latter.
Also tweak the text somewhat and include the fingerprints of the
Master Keys themselves.
(I've merged the existing autogeneration scripts into a single new
one; I've left the old scripts and keys.html around until such time
as the webmonster reviews the changes and plumbs in the new script;
he should remove the old files then.)
[originally from svn r5524]
[this svn revision also touched putty-website]
of polishing to bring them to what I think should in principle be
release quality. Unlike the unfix.org patches themselves, this
checkin enables IPv6 by default; if you want to leave it out, you
have to build with COMPAT=-DNO_IPV6.
I have tested that this compiles on Visual C 7 (so the nightlies
_should_ acquire IPv6 support without missing a beat), but since I
don't have IPv6 set up myself I haven't actually tested that it
_works_. It still seems to make correct IPv4 connections, but that's
all I've been able to verify for myself. Further testing is needed.
[originally from svn r5047]
[this svn revision also touched putty-wishlist]
line for every single .but file at the bottom of each page of the
HTML PuTTY docs. However, we can't _always_ replace that with a
single SVN revision, because there isn't always one available (SVN
still allows mixed working copies in which some files are
deliberately checked out against a different revision).
Hence, here's a mechanism for doing better. It uses `svnversion .'
to determine _whether_ a single revision number adequately describes
the current directory, and replaces all the version IDs with that if
so. If it can't do that, it uses the version IDs as before.
Also, this allows an explicit version string to be passed on the
make command line which will override _both_ these possibilities, so
that release documentation can be clearly labelled with the release
version number.
[originally from svn r4804]
fit in the text output format. If only to stop myself getting
pestered with cron stderr messages every night, here are some
changes that remove over-long code lines from the PuTTY manual.
[originally from svn r4238]
- update usage info in tools
- ack, plink is over 24 lines now
- update man pages for Unix version
- Doc changes:
- move long description from (GUI) "config" to "using"
- sorry if complete specification isn't what this section is meant for,
but if you only read "using" it was hard to find.
- ensure enough references to this made in other sections (GUI,
command-line)
- update instance of plink usage info
[originally from svn r3740]
Updated manual to reflect reality (e.g. usage messages, '-p port' not actually
implemented, sprinkle references to '-i keyfile').
(I've put "Release 0.53" in the messages; let's hope this doesn't cause a
flood of "where is 0.53?" email.)
I don't guarantee that the result is entirely sane and sensible in all
respects, but it is at least consistent.
[originally from svn r1951]
of scp.c, psftp.c and plink.c into it. Additionally, add `batch
mode', in which all the interactive prompts (bad host key, log file
exists, insecure cipher, password prompt) are disabled and safe
responses are assumed. (The idea being that if you run PSCP, for
example, in a cron job then you'd probably rather it failed and
exited instead of leaving the cron job wedged while it waits for
user input that will never arrive.)
[originally from svn r1525]
PuTTY now has a complete manual. Stylistic review, content review
and indexing are yet to do, but at least there's some plausible text
in every section now.
[originally from svn r1460]
than \e when describing button names and menu items: the "Foo"
button rather than the _Foo_ button. Certainly consistent use of
either is better than the mixed use of both we had before :-)
[originally from svn r1420]
