hadn't previously noticed, but Pango was helpfully re-reversing text
that PuTTY's own bidi module had already reversed, leading to Arabic
text being wrongly displayed and also total chaos when you move the
cursor over it or try to cut and paste it.
[originally from svn r9294]
by introducing a wrapper around an individual unifont which falls back
to Pango (which already has built-in fallback) in the case where the
selected font doesn't support the glyph in question.
The wrapper itself is a (vestigial) subclass of unifont, to minimise
disturbance at the call sites.
[originally from svn r9293]
individual font implementation as wchar_t, rather than having to be
converted by the client into the appropriate MBCS/SBCS.
This also means I can remove 'real_charset' from the public-facing
contents of the unifont structure.
[originally from svn r9292]
constructed it it won't be deleted again by 'make clean'. The effect
is that not only does this work (as r9288 arranged),
./configure; make plink
but these work too:
./configure; make; make clean; make plink
./configure; make; make distclean; ./configure; make plink
[originally from svn r9290]
[r9288 == a4424bfd85]
font operations are now done directly using Xlib calls, and the only
interaction with GDK within the x11font mechanism is to get the X ids
for drawables, GCs and the X display itself.
This should remove an obstacle to porting to GTK3, and also makes the
XFontStruct for loaded fonts more readily available, which I hope will
come in handy for another plan I have in mind.
[originally from svn r9289]
makefile) as a side effect of running mkfiles.pl.
The automake docs observe that the BUILT_SOURCES list is only
automatically built by plain 'make' or 'make all' or a couple of other
targets, so the sequence './configure && make plink' from a freshly
unpacked tar file would previously fail for lack of empty.h.
If empty.h had important _content_ that needed to be built at compile
time, of course, I wouldn't be able to fix it like this; but since the
only important thing is the timestamp, I can just make sure it already
exists at the time of first build.
[originally from svn r9288]
from forwarding data sources which will be good enough to last until
we close the socket, in the form of the override_throttle() functions.
So this finishes up the work in r9283, by manufacturing outgoing EOF
in response to incoming CLOSE on all channel types.
[originally from svn r9284]
[r9283 == c54e228d04]
incoming CHANNEL_CLOSE, if it's the main session channel. The idea is
that invocations such as 'plink -T hostname sh' (running a shell
without a remote pty) can be exited by typing 'exit' to the remote
shell, without plink blocking forever waiting for outgoing EOF.
I think it would be better to do the same for all other channel types
too, but that would need an extra API call which I haven't
implemented yet.
[originally from svn r9283]
backend should unilaterally assume outgoing EOF when it sees incoming
EOF, if and only if the main session channel is talking to a pty.
(Because ptys don't have a strong concept of EOF in the first place,
that seems like a sensible place to draw the line.) This fixes a bug
introduced by today's revamp in which if you used Unix Plink to run a
console session it would hang after you hit ^D - because the server
had sent EOF, but it was waiting for a client-side EOF too.
[originally from svn r9282]
data channels. Should comprehensively fix 'half-closed', in principle,
though it's a big and complicated change and so there's a good chance
I've made at least one mistake somewhere.
All connections should now be rigorous about propagating end-of-file
(or end-of-data-stream, or socket shutdown, or whatever) independently
in both directions, except in frontends with no mechanism for sending
explicit EOF (e.g. interactive terminal windows) or backends which are
basically always used for interactive sessions so it's unlikely that
an application would be depending on independent EOF (telnet, rlogin).
EOF should now never accidentally be sent while there's still buffered
data to go out before it. (May help fix 'portfwd-corrupt', and also I
noticed recently that the ssh main session channel can accidentally
have MSG_EOF sent before the output bufchain is clear, leading to
embarrassment when it subsequently does send the output).
[originally from svn r9279]
of preference so that the later ones overwrite the configured stuff
from the older ones, test in decreasing order of preference and stop
as soon as one is successful. Fixes a problem in which
autoconfiguration on a system containing only GTK 1 would go wrong
because the _failed_ test for GTK 2 would overwrite some but not all
of the variables set by the successful test for v1.
[originally from svn r9270]
runs configure at the top level rather than the unix subdirectory. I'm
getting into the idea of even doing it that way myself, because then I
can do VPATH builds from the same source tree elsewhere.
(Autoconf seems to be fine with doing multiple VPATH builds from the
same source tree in different build directories, but gets upset if you
try to do a VPATH build when you've done a normal build in the real
configure directory. So this way I do what autoconf sees as _only_
VPATH builds.)
[originally from svn r9269]
policies before and after r9178, and hence able to talk to both
0.60-like and 0.61-like clients.
I had failed to consider that many pieces of code derived from PuTTY
would have imported the Pageant client code, so we shouldn't randomly
stop supporting things just because _we_ aren't using them any more.
[originally from svn r9264]
[r9178 == af78191a9c]
error, we should also read the corresponding password inputs from
/dev/tty. That way, redirection of Plink's standard input will play
nicely with SSH sessions that need interactive login.
(This is what we get for disdaining getpass(3) and going it alone, of
course. But we had no choice, due to the extra output part way through
keyboard-interactive.)
[originally from svn r9262]
I think I have to consider this to be a separate but related change to
the wishlist item 'pscp-filemodes'; that was written before the Unix
port existed, and referred to the ability to configure the permissions
used for files copied from Windows to Unix - which is still not done.
[originally from svn r9260]
nonstandard port number when loading a saved session.
Occurs because those tools include be_none.c which defines no entries
in backends[] at all, as a result of which settings.c doesn't
recognise the word 'ssh' in the saved session's protocol field and
instead sets the protocol to something idiotic - which _then_ means
that when pscp.c forces the protocol to PROT_SSH, it also resets the
port number as it would when overriding a saved session specifying a
protocol other than SSH.
The immediate solution is to define a new be_ssh.c citing only
ssh_backend, and include that in the SSH-only tools. However, I wonder
if a better approach (perhaps when I redesign session loading and
saving) would be not to be so clever, and just have all the tools
contain a complete list of known protocol names for purposes of
understanding what's in the saved session data, and complain if you
try to use one they don't know how to actually speak.
[originally from svn r9254]
'mkfiles.pl -u', it will do its normal processing, then run mkauto.sh
to regenerate configure and Makefile.in, then run configure in the
Unix subdirectory to regenerate unix/Makefile. So it's a handy
one-stop shop for going all the way from a modified Recipe to the
end-product Unix makefile, if you're adding source files during
development.
[originally from svn r9242]
the real configure script from the unix subdirectory, but with cwd
unchanged so that you end up doing a VPATH build in the top-level
source directory.
Should, ideally, placate the people who expect 'configure' to be at
the top level, while still letting _me_ keep all the Unix-specific
stuff in the Unix subdirectory.
[originally from svn r9241]
--without-gtk as a means of manually overriding the makefile into one
building the command-line tools only (as it would if GTK were not
found at all at configure time).
[originally from svn r9240]
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
on success rather than to $LIBS, because it's only used in the GUI
tools and we don't want the command-line tools linked against it.
[originally from svn r9238]
(In an embarrassingly silly way, too. No end of difficult stuff about
Conf serialisation done with great care and working just fine, and
then a trivial goof in using sscanf lets the whole lot down.)
[originally from svn r9237]
revision ('Custom build r1234'). Those builds were passing
'-DSVN_REV=r1234' to version.c, instead of -DSVN_REV=1234 as they
should have, leading to silly run-time version messages such as
'plink: Custom build rr9226'.
To chop the r off the front of the revision string passed in, I've
used a bashism in mkunxarc.sh. I think this is an acceptable extra
dependency.
[originally from svn r9229]
which GTK version you want to build with if both are installed. Based
on a patch by Malcolm Smith, though somewhat modified.
[originally from svn r9228]
files which provide auto-detection of GTK 1 and GTK 2. This makes it
easier for casual PuTTY developers to rerun autoconf for their own
purposes without having to install obscure extra packages. Obviously
the resulting configure script will not know how to detect whichever
version of GTK they didn't have support for, so it won't be product-
quality by my standards, but it should be good enough that they can
prepare unrelated patches to send to us.
[originally from svn r9227]
authentication. We should now produce an Event Log entry for every
authentication attempted and every authentication failure; meanwhile,
messages in the PuTTY window will not be generated for the failure of
auth types unless we also announced in the PuTTY window that we were
trying them. (GSSAPI was getting the latter wrong, leading to spurious
'Access denied' for many users of 0.61.)
[originally from svn r9226]
SSH_AUTH_SOCK is defined to the empty string. (Because a common way to
'unset' it is to run commands like 'SSH_AUTH_SOCK= putty -load thing'.)
[originally from svn r9225]
(o,p,r,s). They are displayed in Windows by actually writing the
centred one (q) with a vertical offset, in case fonts don't have the
offset versions; this requires terminal.c to separate those characters
into distinct calls to do_text(). Unfortunately, it was only breaking
up a text-drawing call _before_ one of those characters, not after
one. Spotted by Robert de Bath.
[originally from svn r9221]
loop that fetches the next item using conf_get_str_strs and passing
the previous key as a parameter, because the previous key will have
been freed by the intervening conf_del_str_str. Instead, use the
technique of repeatedly using conf_get_str_nthstrkey with index 0 and
deleting what comes back, as PSCP and PSFTP do.
Spotted by Minefield with the aid of Jacob, or possibly vice versa.
[originally from svn r9220]
with the entries from the source one, otherwise add234 will keep
failing ("this key already exists"). Completely broke Plink, ahem.
[originally from svn r9218]
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
website _wasn't_ missing - I just looked straight past it somehow.
Fold the two versions together into one more complete than either.
[originally from svn r9206]
- for 'ixion' read 'atreus' throughout
- the signature-checking commands needed minor modifications to cope
with more *sums files
- stated a few things explicitly which were previously implied, in
case the next inter-release gap is also long enough for me to
forget them.
[originally from svn r9205]
