Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Koichi Murase <myoga.murase@gmail.com>
Newsgroups: gnu.bash.bug
Subject: [PATCH] Fix a problem that shadow `bind -x' does not work
Date: Wed, 18 Dec 2019 17:01:31 +0800
Lines: 161
Approved: bug-bash@gnu.org
Message-ID: <mailman.1068.1576659711.1979.bug-bash@gnu.org>
References: <CAFLRLk9E3_996wJdkUc5AZs1FsE4J-hb2+TwWeJyvJVPS8qovw@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="0000000000007d67180599f6b156"
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Precedence: list
Xref: csiph.com gnu.bash.bug:15743

--0000000000007d67180599f6b156
Content-Type: text/plain; charset="UTF-8"

Hi, I have still several patches related to `bind'. My previous
patches are processed now so let me post them.

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux hp2019 5.2.13-200.fc30.x86_64 #1 SMP Fri Sep 6
14:30:40 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.0
Patch Level: 11
Release Status: maint

Description:

  When the key sequence of a binding is a prefix of other bindings
  (let me call it a shadow binding in this report), the shadow binding
  is triggered when the user input does not match any of the other
  bindings or there is no input within timeout specified by the
  readline variable `keyseq-timeout'. When such a shadow binding is
  the one by `bind -x', Bash fails to find the appropriate unix
  command and produces error message or triggers a wrong command.

  This is reproduced in Bash 4.4, 5.0 and current devel branch. Bash
  4.3 works properly in simple cases, but it still fails in complex
  test cases. In Bash from 3.0 to 4.2, it causes segmentation
  fault.

  The problem is internally caused by the unupdated content of the array
  `rl_executing_keyseq' on unmatched user inputs or timeout. This array
  is used as a key sequence to find the unix command in `cmd_xmap'.

Repeat-By:

  Test case 1:

  With the following settings, after typing `C-t' the command `echo
  world' is expected to be executed after the 500ms delay specified by
  the default value of the readline variable `keyseq-timeout'. However
  we get an error message "bash_execute_unix_command: ..." instead:

  $ LANG=C bash --norc
  $ bind -v | grep keyseq-timeout
  set keyseq-timeout 500
  $ bind '"\C-t\C-t":"hello"'
  $ bind -x '"\C-t":echo world'
  $ <-- <C-t><wait 500ms>
  bash: bash_execute_unix_command: cannot find keymap for command


  Test case 2:

  When the keyseq `\C-t\C-t' binds to `bind -x', `\C-t' + delay
  invokes the command for `\C-t\C-t' instead fo the one for `\C-t'.

  $ LANG=C bash --norc
  $ bind -x '"\C-t\C-t":echo hello'
  $ bind -x '"\C-t":echo world'
  $ <-- <C-t><wait 500ms>
  hello     #<-- expected result is "world"


  Test case 3:

  Similar results can also be obtained by inputting some unexpected
  key before the timeout comes.

  $ LANG=C bash --norc
  $ bind '"\C-t\C-t":"hello"'
  $ bind -x '"\C-t":echo world'
  $ <-- <C-t>a
  bash: bash_execute_unix_command: cannot find keymap for command
  $ a

  Test case 4:

  This is just a test case for code coverage. Internally the following
  three errors are produced by different control paths so we need to
  fix all of these control paths.

  $ LANG=C bash --norc
  $ bind '"\C-t\C-t\C-t\C-t":"hello"'
  $ bind -x '"\C-t":echo world'
  $ <-- <C-t><C-t><C-t>a
  bash: bash_execute_unix_command: cannot find keymap for command
  $
  bash: bash_execute_unix_command: cannot find keymap for command
  $
  bash: bash_execute_unix_command: cannot find keymap for command
  $ a


Fix:

  I attach a patch. In the patch the following lines are inserted to
  needed places. I think in principle just `rl_key_sequence_length--'
  should work, but I have written as in the patch for safety.

    if (rl_key_sequence_length > 0)
      rl_executing_keyseq[--rl_key_sequence_length] = '\0';

Best regards,
Koichi

--0000000000007d67180599f6b156
Content-Type: application/octet-stream; 
	name="0001-_rl_dispatch_subseq-update-rl_executing_keyseq-on-un.patch"
Content-Disposition: attachment; 
	filename="0001-_rl_dispatch_subseq-update-rl_executing_keyseq-on-un.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_k4b2fiid0>
X-Attachment-Id: f_k4b2fiid0

RnJvbSA2OGE1NGFiNTRmODQ1MmIxYTI4NWU4OWEyZDBlY2VkMjIzMGEwNTU5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBLb2ljaGkgTXVyYXNlIDxteW9nYS5tdXJhc2VAZ21haWwuY29t
PgpEYXRlOiBXZWQsIDE4IERlYyAyMDE5IDE0OjQxOjIzICswODAwClN1YmplY3Q6IFtQQVRDSF0g
X3JsX2Rpc3BhdGNoX3N1YnNlcTogdXBkYXRlIHJsX2V4ZWN1dGluZ19rZXlzZXEgb24gdW5tYXRj
aGVkCiBrZXlzZXEgb3IgdGltZW91dAoKLS0tCiBsaWIvcmVhZGxpbmUvcmVhZGxpbmUuYyB8IDE0
ICsrKysrKysrKysrKystCiAxIGZpbGUgY2hhbmdlZCwgMTMgaW5zZXJ0aW9ucygrKSwgMSBkZWxl
dGlvbigtKQoKZGlmZiAtLWdpdCBhL2xpYi9yZWFkbGluZS9yZWFkbGluZS5jIGIvbGliL3JlYWRs
aW5lL3JlYWRsaW5lLmMKaW5kZXggMDgwNWZkNGIuLmM5YTM0ZGVmIDEwMDY0NAotLS0gYS9saWIv
cmVhZGxpbmUvcmVhZGxpbmUuYworKysgYi9saWIvcmVhZGxpbmUvcmVhZGxpbmUuYwpAQCAtODcw
LDYgKzg3MCw4IEBAIF9ybF9kaXNwYXRjaF9zdWJzZXEgKHJlZ2lzdGVyIGludCBrZXksIEtleW1h
cCBtYXAsIGludCBnb3Rfc3Vic2VxKQogCSAgICBfcmxfcHJldl9tYWNyb19rZXkgKCk7CiAJICBl
bHNlCiAJICAgIF9ybF91bmdldF9jaGFyICAoa2V5KTsKKwkgIGlmIChybF9rZXlfc2VxdWVuY2Vf
bGVuZ3RoID4gMCkKKwkgICAgcmxfZXhlY3V0aW5nX2tleXNlcVstLXJsX2tleV9zZXF1ZW5jZV9s
ZW5ndGhdID0gJ1wwJzsKIAkgIHJldHVybiAtMjsKIAl9CiAgICAgICBlbHNlIGlmIChnb3Rfc3Vi
c2VxKQpAQCAtODgyLDYgKzg4NCw4IEBAIF9ybF9kaXNwYXRjaF9zdWJzZXEgKHJlZ2lzdGVyIGlu
dCBrZXksIEtleW1hcCBtYXAsIGludCBnb3Rfc3Vic2VxKQogCSAgICBfcmxfcHJldl9tYWNyb19r
ZXkgKCk7CiAJICBlbHNlCiAJICAgIF9ybF91bmdldF9jaGFyIChrZXkpOworCSAgaWYgKHJsX2tl
eV9zZXF1ZW5jZV9sZW5ndGggPiAwKQorCSAgICBybF9leGVjdXRpbmdfa2V5c2VxWy0tcmxfa2V5
X3NlcXVlbmNlX2xlbmd0aF0gPSAnXDAnOwogCSAgcmV0dXJuIC0xOwogCX0KICAgICAgIGVsc2UK
QEAgLTk3NCw3ICs5NzgsMTEgQEAgX3JsX2Rpc3BhdGNoX3N1YnNlcSAocmVnaXN0ZXIgaW50IGtl
eSwgS2V5bWFwIG1hcCwgaW50IGdvdF9zdWJzZXEpCiAJICAJX3JsX3B1c2hlZF9pbnB1dF9hdmFp
bGFibGUgKCkgPT0gMCAmJgogCQlfcmxfZGlzcGF0Y2hpbmdfa2V5bWFwW0FOWU9USEVSS0VZXS5m
dW5jdGlvbiAmJgogCQlfcmxfaW5wdXRfcXVldWVkIChfcmxfa2V5c2VxX3RpbWVvdXQqMTAwMCkg
PT0gMCkKLQkgICAgcmV0dXJuIChfcmxfc3Vic2VxX3Jlc3VsdCAoLTIsIG1hcCwga2V5LCBnb3Rf
c3Vic2VxKSk7CisJICAgIHsKKwkgICAgICBpZiAocmxfa2V5X3NlcXVlbmNlX2xlbmd0aCA+IDAp
CisJCXJsX2V4ZWN1dGluZ19rZXlzZXFbLS1ybF9rZXlfc2VxdWVuY2VfbGVuZ3RoXSA9ICdcMCc7
CisJICAgICAgcmV0dXJuIChfcmxfc3Vic2VxX3Jlc3VsdCAoLTIsIG1hcCwga2V5LCBnb3Rfc3Vi
c2VxKSk7CisJICAgIH0KIAogCSAgbmV3a2V5ID0gX3JsX3N1YnNlcV9nZXRjaGFyIChrZXkpOwog
CSAgaWYgKG5ld2tleSA8IDApCkBAIC0xMDY1LDYgKzEwNzMsOCBAQCBfcmxfc3Vic2VxX3Jlc3Vs
dCAoaW50IHIsIEtleW1hcCBtYXAsIGludCBrZXksIGludCBnb3Rfc3Vic2VxKQogCV9ybF9wcmV2
X21hY3JvX2tleSAoKTsKICAgICAgIGVsc2UKIAlfcmxfdW5nZXRfY2hhciAoa2V5KTsKKyAgICAg
IGlmIChybF9rZXlfc2VxdWVuY2VfbGVuZ3RoID4gMCkKKwlybF9leGVjdXRpbmdfa2V5c2VxWy0t
cmxfa2V5X3NlcXVlbmNlX2xlbmd0aF0gPSAnXDAnOwogICAgICAgX3JsX2Rpc3BhdGNoaW5nX2tl
eW1hcCA9IG1hcDsKICAgICAgIHJldHVybiAtMjsKICAgICB9CkBAIC0xMDc1LDYgKzEwODUsOCBA
QCBfcmxfc3Vic2VxX3Jlc3VsdCAoaW50IHIsIEtleW1hcCBtYXAsIGludCBrZXksIGludCBnb3Rf
c3Vic2VxKQogCV9ybF9wcmV2X21hY3JvX2tleSAoKTsKICAgICAgIGVsc2UKIAlfcmxfdW5nZXRf
Y2hhciAoa2V5KTsKKyAgICAgIGlmIChybF9rZXlfc2VxdWVuY2VfbGVuZ3RoID4gMCkKKwlybF9l
eGVjdXRpbmdfa2V5c2VxWy0tcmxfa2V5X3NlcXVlbmNlX2xlbmd0aF0gPSAnXDAnOwogICAgICAg
X3JsX2Rpc3BhdGNoaW5nX2tleW1hcCA9IG1hcDsKICAgICAgIHJldHVybiAtMTsKICAgICB9Ci0t
IAoyLjIxLjAKCg==
--0000000000007d67180599f6b156--