X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Date: Sun, 19 Jul 2009 12:30:37 +0100 Message-ID: <416096c60907190430o51aa6ebx4786ef002f175fc4@mail.gmail.com> Subject: Patch to make readline parse CSI keycodes properly From: Andy Koppe To: Cygwin Tech List Content-Type: multipart/mixed; boundary=0016364ed258b3d060046f0d5960 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com --0016364ed258b3d060046f0d5960 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit When pressing an unbound key or key combination in bash and other readline programs, somewhat cryptic characters are often inserted into the command line. For example, you get "~" for Insert, "4~" for F12, or ";5A" for Ctrl+Up. This can be rather confusing and annoying. The reason is that readline does not parse control sequences as defined in section 5.4 of the ECMA-48 standard correctly. VT100 terminals and its numerous descendants use those for many keys or key combinations that don't have single-character codes. They start with the control sequence introducer (CSI), normally represented by "\e[", followed by parameter and intermediate bytes in the range from 0x20 to 0x3F, followed by a final byte in the range from 0x40 to 0x7E. Readline, at least in its default config, stops parsing these sequences after the first byte following the "\e[", leaving any remaining bytes to spill onto the command line. As far as I can see, there's currently no way to address this short of explicitly binding all the CSI keycodes to nothing. (Well, actually, a single binding seems to suffice for codes that differ only in the last character, but that doesn't help with the F-keys and the likes of Insert.) That's a rather long list though, which would slow down startup and lead to an explosion in the number of keymaps allocated internally by readline. Hence the attached small patch for the readline source, which avoids such inefficiencies. It defines a function called 'skip-csi-seq' that skips over the parameter, intermediate, and final bytes. This is assigned to '\e['. Generally in readline, bindings for longer sequences take precedence over shorter ones, which ensures that CSI sequences that do have functions bound to them continue to work. Here's the result in the output of 'bind': $ bind -p | grep e\\[ "\e[D": backward-char "\e[H": beginning-of-line "\e[3~": delete-char "\e[F": end-of-line "\e[C": forward-char "\e[B": next-history "\e[A": previous-history "\e[": skip-csi-seq It's working correctly here, including when adding bindings for longer keycodes: no more funny characters when accidentally hitting the wrong key. Please consider the patch for inclusion into the readline package. Regards, Andy --0016364ed258b3d060046f0d5960 Content-Type: application/octet-stream; name="rl_skip_csi_seq.patch" Content-Disposition: attachment; filename="rl_skip_csi_seq.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fxbkq5o40 LS0tIGVtYWNzX2tleW1hcC5jCTIwMDktMDEtMDQgMTk6MzI6MzIuMDAwMDAw MDAwICswMDAwCisrKyBlbWFjc19rZXltYXAuYwkyMDA5LTA3LTE5IDA4OjIz OjMyLjc5Njg3NTAwMCArMDEwMApAQCAtNDE3LDcgKzQxNyw3IEBACiAgIHsg SVNGVU5DLCBybF9kb19sb3dlcmNhc2VfdmVyc2lvbiB9LAkvKiBNZXRhLVog Ki8KIAogICAvKiBTb21lIG1vcmUgcHVuY3R1YXRpb24uICovCi0gIHsgSVNG VU5DLCAocmxfY29tbWFuZF9mdW5jX3QgKikweDAgfSwJCS8qIE1ldGEtWyAq LwkvKiB3YXMgcmxfYXJyb3dfa2V5cyAqLworICB7IElTRlVOQywgcmxfc2tp cF9jc2lfc2VxIH0sCQkJLyogTWV0YS1bICovCS8qIHdhcyBybF9hcnJvd19r ZXlzICovCiAgIHsgSVNGVU5DLCBybF9kZWxldGVfaG9yaXpvbnRhbF9zcGFj ZSB9LAkvKiBNZXRhLVwgKi8KICAgeyBJU0ZVTkMsIChybF9jb21tYW5kX2Z1 bmNfdCAqKTB4MCB9LAkJLyogTWV0YS1dICovCiAgIHsgSVNGVU5DLCAocmxf Y29tbWFuZF9mdW5jX3QgKikweDAgfSwJCS8qIE1ldGEtXiAqLwotLS0gZnVu bWFwLmMJMjAwOS0wMS0wNCAxOTozMjozMy4wMDAwMDAwMDAgKzAwMDAKKysr IGZ1bm1hcC5jCTIwMDktMDctMTkgMDg6MjU6MzQuOTA2MjUwMDAwICswMTAw CkBAIC0xMjMsNiArMTIzLDcgQEAKICAgeyAicmV2ZXJ0LWxpbmUiLCBybF9y ZXZlcnRfbGluZSB9LAogICB7ICJzZWxmLWluc2VydCIsIHJsX2luc2VydCB9 LAogICB7ICJzZXQtbWFyayIsIHJsX3NldF9tYXJrIH0sCisgIHsgInNraXAt Y3NpLXNlcSIsIHJsX3NraXBfY3NpX3NlcSB9LAogICB7ICJzdGFydC1rYmQt bWFjcm8iLCBybF9zdGFydF9rYmRfbWFjcm8gfSwKICAgeyAidGFiLWluc2Vy dCIsIHJsX3RhYl9pbnNlcnQgfSwKICAgeyAidGlsZGUtZXhwYW5kIiwgcmxf dGlsZGVfZXhwYW5kIH0sCi0tLSByZWFkbGluZS5oCTIwMDktMDctMTkgMDU6 Mjg6MzAuMDAwMDAwMDAwICswMTAwCisrKyByZWFkbGluZS5oCTIwMDktMDct MTkgMDg6MjM6MzguNTQ2ODc1MDAwICswMTAwCkBAIC0xOTcsNiArMTk3LDcg QEAKIC8qIE1pc2NlbGxhbmVvdXMgYmluZGFibGUgY29tbWFuZHMuICovCiBl eHRlcm4gaW50IHJsX2Fib3J0IFBBUkFNUygoaW50LCBpbnQpKTsKIGV4dGVy biBpbnQgcmxfdHR5X3N0YXR1cyBQQVJBTVMoKGludCwgaW50KSk7CitleHRl cm4gaW50IHJsX3NraXBfY3NpX3NlcSBQQVJBTVMoKGludCwgaW50KSk7CiAK IC8qIEJpbmRhYmxlIGNvbW1hbmRzIGZvciBpbmNyZW1lbnRhbCBhbmQgbm9u LWluY3JlbWVudGFsIGhpc3Rvcnkgc2VhcmNoaW5nLiAqLwogZXh0ZXJuIGlu dCBybF9oaXN0b3J5X3NlYXJjaF9mb3J3YXJkIFBBUkFNUygoaW50LCBpbnQp KTsKLS0tIHRleHQuYwkyMDA5LTAxLTA0IDE5OjMyOjM0LjAwMDAwMDAwMCAr MDAwMAorKysgdGV4dC5jCTIwMDktMDctMTkgMDg6MjM6NDUuODkwNjI1MDAw ICswMTAwCkBAIC01NzEsNiArNTcxLDE4IEBACiB9CiAKIGludAorcmxfc2tp cF9jc2lfc2VxIChjb3VudCwgYykKKyAgICAgaW50IGNvdW50LCBjOworewor ICBSTF9TRVRTVEFURShSTF9TVEFURV9NT1JFSU5QVVQpOworICBkbworICAg IGMgPSBybF9yZWFkX2tleSAoKTsKKyAgd2hpbGUgKGMgPj0gMHgyMCAmJiBj IDwgMHg0MCk7CisgIFJMX1VOU0VUU1RBVEUoUkxfU1RBVEVfTU9SRUlOUFVU KTsKKyAgcmV0dXJuIDA7Cit9CisKK2ludAogcmxfYXJyb3dfa2V5cyAoY291 bnQsIGMpCiAgICAgIGludCBjb3VudCwgYzsKIHsK --0016364ed258b3d060046f0d5960 Content-Type: text/plain; charset=us-ascii -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple --0016364ed258b3d060046f0d5960--