[Bash-completion-devel] Expect buffering fixes

[Crestez Dan Leonard]

Unit tests (as in ./runUnit) don't work reliably for me on Debian
unstable. I get a bunch of more-or-less random failures on some tests.
On a complete run I can get anywhere between 5 and 15 unexpected
failures.

After some digging with runtest --debug I am convinced that the regexps
in match_items are to blame. I can reliably pass all tests with the
following patch (inline):

diff --git a/test/lib/library.exp b/test/lib/library.exp
index 4d23b18..f8c41b2 100644
--- a/test/lib/library.exp
+++ b/test/lib/library.exp
@@ -618,9 +618,9 @@ proc match_items {items test {prompt /@} {size 20}}
{
         }; # for
         if {[llength $items] == 1} {
             expect {
-                -re "^$expected\r\n$" { set result true }
+                -re "^$expected\r\n" { set result true }
                 # NOTE: The optional space ( ?) depends on whether -o
nospace is active
-                -re "^$expected ?$" { set result true }
+                -re "^$expected ?" { set result true }
                 -re "^$prompt$" {set result false; break }
                 "\r\n" { set result false; break }
                 default { set result false; break }

In a -re clause a $ means end of buffer, not end of line. If expect
happens to receive more data then those clauses will _never_ match. A $
should only be used when it's known that the shell with not write
additional stuff (like after a prompt).

I guess it worked for such a long time because somehow buffering was
always happening the same way. Maybe it's because I have bash-4.1 and a
2.6.32 kernel.

-----

On a somewhat related note I looked for a way to remove sleep statements
from sync_after_int. Everything seems to work reliably if I match ^C\r\n
explicitly. If I remove sleep statements but don't change the expected
expression I can reproduce the compgen bug discussed in a different
thread (but not every time). Here's the patch, again inline:

diff --git a/test/lib/library.exp b/test/lib/library.exp
index f8c41b2..b5f914d 100644
--- a/test/lib/library.exp
+++ b/test/lib/library.exp
@@ -833,19 +833,22 @@ proc start_bash {} {
 # Send signals QUIT & INT.
 # @param string $prompt  (optional) Bash prompt.  Default is "/@"
 proc sync_after_int {{prompt /@}} {
+
+    # expect_after will uses this.
     set test "Sync after INT"
-    sleep .1
-    send \031\003;  # QUIT/INT
-    # Wait to allow bash to become ready
-    # See also:
http://lists.alioth.debian.org/pipermail/bash-completion-devel/
-    #           2010-February/002566.html
-    sleep .1
+
+    # Send QUIT/INT
+    send \031\003;
+
     # NOTE: Regexp `.*' causes `expect' to discard previous unknown
output.
     #       This is necessary if a completion doesn't match
expectations.
     #       For instance with `filetype_xspec' completion (e.g. `kdvi')
if
     #       one expects `.txt' as a completion (wrong, because it isn't
     #       there), the unmatched completions need to be cleaned up.
-    expect -re ".*$prompt$"
+
+    # NOTE: Match ^C\r\n explicitly so that we don't match a previous
+    #       unmatched prompt by accident.
+    expect -re ".*\\^C\\r\\n$prompt$"
 }
 
 

On my machines this reduces ./runUnit time from 40 to 10 seconds and I
find it very helpful.

I pushed this is in the expect-fixes branch in git. It would be great if
you could confirm my findings; I don't want to cause regressions.

http://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=shortlog;h=refs/heads/expect-fixes