This repository has been archived by the owner on Apr 19, 2024. It is now read-only.
Bugfix #76
Closed
Bugfix #76
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…DISPLAY has invalid contents). Simply refuse to try X forwarding in this circumstance. git-svn-id: svn://svn.tartarus.org/sgt/putty@8390 cda61777-01e9-0310-a592-d414129be87e
…n socket. This could cause Unix PuTTY to segfault when X forwarding over an SSH session through a proxy. (sk_getaddr() wouldn't cope either -- in that case, add an assertion to make it more obvious; I don't think it should ever happen.) git-svn-id: svn://svn.tartarus.org/sgt/putty@8391 cda61777-01e9-0310-a592-d414129be87e
git-svn-id: svn://svn.tartarus.org/sgt/putty@8392 cda61777-01e9-0310-a592-d414129be87e
git-svn-id: svn://svn.tartarus.org/sgt/putty@8393 cda61777-01e9-0310-a592-d414129be87e
git-svn-id: svn://svn.tartarus.org/sgt/putty@8394 cda61777-01e9-0310-a592-d414129be87e
incorporates the environment variable CFLAGS into its output. Avoid exporting our version of it from the Makefile (which actually causes build failures, since quoting phase issues mean that the backticks in our version end up unexpanded). git-svn-id: svn://svn.tartarus.org/sgt/putty@8399 cda61777-01e9-0310-a592-d414129be87e
makefile with make's own $(shell ...) function, which means that gtk-config and krb5-config and so on only get run once per make invocation instead of once per gcc invocation. git-svn-id: svn://svn.tartarus.org/sgt/putty@8400 cda61777-01e9-0310-a592-d414129be87e
autoconf makefile. git-svn-id: svn://svn.tartarus.org/sgt/putty@8401 cda61777-01e9-0310-a592-d414129be87e
case of double-width text (ESC # 3, ESC # 4, ESC # 6), because the string passed to it was not truncated to the same width as the clipping rectangle. (In fact, it _can't_ reliably be, in the case where the window width is odd.) So instead we just assert that we managed to _at least_ fill the clipping rectangle, not that we exactly filled it. The problem is easily reproduced by sending ESC # 8 (fill the screen with Es) followed by ESC # 3. It doesn't typically happen, though, if you _manually_ fill the screen with Es, because in that case PuTTY's terminal buffer ends up being filled with CSET_ACP | 'E' or similar, which means that general_textout() never gets called because one of the other branches of do_text_internal() does the work instead. ESC # 8 will fill the terminal buffer with genuine _Unicode_ 'E' characters, which exercises the failing code path. git-svn-id: svn://svn.tartarus.org/sgt/putty@8403 cda61777-01e9-0310-a592-d414129be87e
git-svn-id: svn://svn.tartarus.org/sgt/putty@8405 cda61777-01e9-0310-a592-d414129be87e
…ntable as unsigned char. This means that passing in a bare char is incorrect on systems where char is signed. Sprinkle some appropriate casts to prevent this. git-svn-id: svn://svn.tartarus.org/sgt/putty@8406 cda61777-01e9-0310-a592-d414129be87e
OVERLAPPED structure in output threads, as we already do for input threads. This apparently sorts out a hanging issue with serial ports when trying to do simultaneous read and write, because (GJV says, and it sounds plausible to me) in the absence of that event object Windows signals the file handle itself to notify GetOverlappedResult that it can return - and since the file handle might be being signalled by a read operation instead, that leads to ambiguity. Using an explicit event object in both directions means Windows always knows which way the data is going. Also a trivial fix in handle_output_new(), which was referencing the wrong element of a union due to a copy and paste error. (Since the result was address-taken and cast to void *, this wasn't a functional error, but it was conceptually wrong.) git-svn-id: svn://svn.tartarus.org/sgt/putty@8410 cda61777-01e9-0310-a592-d414129be87e
git-svn-id: svn://svn.tartarus.org/sgt/putty@8411 cda61777-01e9-0310-a592-d414129be87e
only call it when the _last_ mouse button comes back up. Otherwise, xterm mouse tracking will lose a button-up event if you press down two buttons, move the mouse outside the window, then release them one at a time. git-svn-id: svn://svn.tartarus.org/sgt/putty@8425 cda61777-01e9-0310-a592-d414129be87e
read at connection setup time, so don't offer it in the Change Settings dialog box. (In particular, this fixes an assertion failure when selecting Change Settings on a non-SSH connection, since wincfg.c would have added that control to Connection/SSH/X11 when the parent panel Connection/SSH didn't exist. Making the control conditional on the selected protocol would have been sufficient to fix that failure, but I now realise that the setting should never have been presented in mid-session in any case.) git-svn-id: svn://svn.tartarus.org/sgt/putty@8443 cda61777-01e9-0310-a592-d414129be87e
…uced in r7084 at the same time as sensible permissions when writing private key files; however, it causes an assertion failure whenever an attempt is made to append to an existing log file on Unix, and it's not clear what "is_private" *should* do for append, so revert to log file security being the user's responsibility. (Fixes Ubuntu LP#212711.) git-svn-id: svn://svn.tartarus.org/sgt/putty@8461 cda61777-01e9-0310-a592-d414129be87e
…calhost:0" to a Unix-domain socket. This typically works fine when PuTTY is run on the same machine as the X server, but it's broken multi-hop X forwarding through OpenSSH; when OpenSSH creates a proxy X server "localhost:10", it only listens on TCP, not on a Unix-domain socket. Instead, when deciding on the details of the display, we actively probe to see if there's a Unix-domain socket we can use instead, and only use it if it's there, falling back to the specified IP "localhost" if not. Independently, when looking for local auth details in Xauthority for a "localhost" TCP display, we prefer a matching Unix-domain entry, but will fall back to an IP "localhost" entry (which would be unusual, but we don't trust a Windows X server not to do it) -- this is a generalisation of the special case added in r2538 (but removed in r8305, as the automatic upgrade masked the need for it). (This is now done in platform-independent code, so a side-effect is that get_hostname() is now part of the networking abstraction on all platforms.) git-svn-id: svn://svn.tartarus.org/sgt/putty@8462 cda61777-01e9-0310-a592-d414129be87e
git-svn-id: svn://svn.tartarus.org/sgt/putty@8466 cda61777-01e9-0310-a592-d414129be87e
'string' field in a GdkEventKey structure as ISO-8859-1, which was correct for GTK 1.2 but in 2.0 that field is encoded according to the current C library locale. Hence, we now process that field by converting it to UTF-8 via trips through both libc and libcharset, and then let lpage_send() convert from UTF-8 back to whatever it's supposed to actually go down the line in. git-svn-id: svn://svn.tartarus.org/sgt/putty@8470 cda61777-01e9-0310-a592-d414129be87e
my editor, which has defaulted to showing them as explicit ^I for a while now, but it seems like a generally prudent idea in any case.) git-svn-id: svn://svn.tartarus.org/sgt/putty@8472 cda61777-01e9-0310-a592-d414129be87e
prompts packet containing no actual prompts (perhaps due to odd server organisation, or perhaps so it can print a banner message and do nothing else). Previously, the get_userpass_input functions always returned failure when in '-batch' mode, even in this case where no actual input would be required. git-svn-id: svn://svn.tartarus.org/sgt/putty@8490 cda61777-01e9-0310-a592-d414129be87e
…ession, some servers (Debian in particular seems prone to this) send a k-i packet with no prompts and nothing to display. We were printing an extra "Using keyboard-interactive authentication" message in this case. (Introduced by me in r8172, I think.) git-svn-id: svn://svn.tartarus.org/sgt/putty@8492 cda61777-01e9-0310-a592-d414129be87e
UTF-16 when exchanging wchar_t strings with the front end. Enabled by a #define in the platform's header file (one should not promiscuously translate UTF-16 surrogate pairs on 32-bit wchar_t platforms since that could give rise to redundant encoding attacks), which is present on Windows. git-svn-id: svn://svn.tartarus.org/sgt/putty@8495 cda61777-01e9-0310-a592-d414129be87e
local socket _before_ calling the SSH setup functions. This makes no difference to ssh.c itself, but it makes portfwd.c easier to reuse for other purposes (e.g. as a component of a standalone SOCKS server), because now ssh_send_port_open() can itself call pfd_confirm() without the freeze and unfreeze happening in the wrong order. git-svn-id: svn://svn.tartarus.org/sgt/putty@8500 cda61777-01e9-0310-a592-d414129be87e
name the proxy using the global 'appname' variable, instead of statically calling it PuTTY. (Knock-on effect is that PSCP and PSFTP have to declare that variable, though of course they shouldn't ever actually _use_ the X forwarding code. Probably I ought to replace it with a stub nox11fwd.c for those applications.) git-svn-id: svn://svn.tartarus.org/sgt/putty@8501 cda61777-01e9-0310-a592-d414129be87e
git-svn-id: svn://svn.tartarus.org/sgt/putty@8502 cda61777-01e9-0310-a592-d414129be87e
… to a potential crash on "reget" in Unix PSFTP. git-svn-id: svn://svn.tartarus.org/sgt/putty@8516 cda61777-01e9-0310-a592-d414129be87e
…hecking the return from open() and behaved wrongly in the absence of a seed file. git-svn-id: svn://svn.tartarus.org/sgt/putty@8517 cda61777-01e9-0310-a592-d414129be87e
git-svn-id: svn://svn.tartarus.org/sgt/putty@8518 cda61777-01e9-0310-a592-d414129be87e
…grown a means of specifying port numbers, so we should support that. git-svn-id: svn://svn.tartarus.org/sgt/putty@8519 cda61777-01e9-0310-a592-d414129be87e
To connect a specific device, input device ID in host name To connect the default device, input a colon(:) in host name
…ligned on wide-drawn characters.
actually start the adb shell
previous one only fixed it for device id being given
This is mainly to ease testing; I have no idea what effects it will have in the real world, but we believe it to be minimal.
Patch from Matsui Nag to implement xterm's "bracketed paste mode", in which text pasted into the terminal is preceded and followed by special function-key-like escape sequences ESC[200~ and ESC[201~ so that the application can identify it and treat it specially (e.g. disabling auto-indent-same-as-previous-line in text editors). Enabled and disabled by ESC[?2004h and ESC[?2004l, and of course off by default. Signed-off-by: stfn <[email protected]>
…nc with the internal cfg's storage stype. This also fixes the swapped radio button hack as well as some UI bugs.
…adb connections, which also maintains compatibilities with other PuTTY variants. Device serial number can also be used as well, and hopefully some documentations will mention this.
|
1: I put some code in 65b8d31 to make real VS2010 projects, which might interest you; this looks fine regardless. 2-3: I plan to spend some time getting familiar with file settings, this will probably help my understanding, but I don't really get what it's doing enough to just outright merge it. 4-6: Totally fine. I'll see if I can get around to testing 2-3 tomorrow, otherwise I'll just merge the others and leave testing that stuff to my "check file stuff still works" for The Great Next Branch Merge, which has to happen eventually. Thanks. P.S. The whitespace is a bit messed up. If you set Visual Studio's settings -> Text Editor -> C/C++ -> Tabs to "Tab size: 8, Indent Size: 4" you see PuTTY as it was intended. I also recommend "Insert Spaces". I've added a note to myself on https://github.com/FauxFaux/PuTTYTray/wiki/Building-with-VS2010-Express to document this too. |
|
Cool. Thanks for the heads-up on space/tab. Yes the file storage implementation is a bit messy currently. It also leads to hacks into the unix store code to make it compatible, which could be a pain when you merge from upstream later. I wouldn't be surprised if you decide to reimplement the whole functionality yourself. Regarding 65b8d31, did you accidentally check in the generated project files? I thought the purpose of mkfiles.pl is to generate the project files automatically from the recipe. |
FauxFaux
pushed a commit
that referenced
this pull request
Aug 19, 2013
FauxFaux
pushed a commit
that referenced
this pull request
Aug 19, 2013
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Various bug fixes, details below:
Allow mkfiles.pl-generated VC6 project to compile successfully. Tested on VC++2012.
Related to Doesn't save SSH Host Keys into SshHostKeys #11, and a few other bugs like: Upon startuop, directly saving a new session will clear the session list, if all existing sessions are from file and hence auto storage type kicks in.
Apr 29, 2013
adb not working #74