Bugs item #312477, was changed at 2010-04-26 19:35 by Ville Skyttä
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=312477&group_id=100114
Status: Open
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: _filedir unit test fails in C locale with bash 4.1.x, with any locale
with bash 3.2.x
Distribution: None
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
With my usual setting (LANG=en_US.UTF-8) it passes, but:
$ LANG=C ./runUnit _filedir.exp
WARNING: Couldn't find the global config file.
Test Run By scop on Mon Apr 26 19:33:04 2010
Native configuration is x86_64-unknown-linux-gnu
=== unit tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/default.exp as tool-and-target-specific interface file.
Running ./unit/_filedir.exp ...
FAIL: f aé/ should show completions at timeout
FAIL: f aé/ should show completions
=== unit Summary ===
# of expected passes 46
# of unexpected failures 2
/home/scop/cvs/bash-completion/test, bash-4.1.2(1)-release
----------------------------------------------------------------------
>Comment By: Ville Skyttä (scop-guest)
Date: 2010-10-27 20:36
Message:
Thanks, it works as documented in the comments now, and indicates that one test
was unsupported when expected. I'll leave it up to you to decide whether to
close this bug now.
----------------------------------------------------------------------
Comment By: Freddy Vulto (fvu-guest)
Date: 2010-10-26 23:46
Message:
Improved things in commit 20f7d5c. Can you give this a try?
-# Execute this test only when LC_CTYPE matches *UTF-8*
-if {[string first "UTF-8" $::LC_CTYPE] != -1} {
- set test "completing f a<C3><A9> should return g"
+set test "completing f a<C3><A9> should return g when LC_CTYPE=C"
+# Execute this test only on bash >= 4 with LC_CTYPE matching *UTF-8*
+# See also: http://www.mail-archive.com/bash-completion-devel\
+# @lists.alioth.debian.org/msg02265.html
+if {
+ [lindex $::BASH_VERSINFO 0] >= 4 &&
+ [string first "UTF-8" $::LC_CTYPE] != -1
+} {
assert_complete_dir g "f a<C3><A9>/" "fixtures/_filedir"
+} else {
+ unsupported "$test"
}
Todo: also don't execute the test with expect >= 5.44 cause this will probably
give a segmentation fault :-(
----------------------------------------------------------------------
Comment By: Ville Skyttä (scop-guest)
Date: 2010-10-23 13:13
Message:
No crash here (expect 5.43.0).
$ expect -f unicode.exp
spawn bash
aaébbPASS$
----------------------------------------------------------------------
Comment By: Freddy Vulto (fvu-guest)
Date: 2010-10-23 12:38
Message:
I think I found a bug (segmentation fault) in Expect regarding unicode. Can
you confirm this?
$ cat unicode.exp
spawn bash
send "aaébb"
expect -ex "aaébb" {send_user "PASS"}
$ expect -f unicode.exp
spawn bash
aaébbSegmentation fault
See also:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/8ea4b666c2f31cac#
----------------------------------------------------------------------
Comment By: Ville Skyttä (scop-guest)
Date: 2010-10-21 08:50
Message:
Yes, it works with bash 4.1.7 and en_US.UTF-8 for me, and appears to skip the
test with that bash version and LC_ALL=C. I'd expect it to explicitly tell me
that some tests were unsupported/skipped though; with en_US.UTF-8 I get:
=== unit Summary ===
# of expected passes 47
/home/scop/cvs/bash-completion/test, bash-4.1.7(1)-release
...and with LC_ALL=C:
=== unit Summary ===
# of expected passes 46
/home/scop/cvs/bash-completion/test, bash-4.1.7(1)-release
----------------------------------------------------------------------
Comment By: Freddy Vulto (fvu-guest)
Date: 2010-10-21 00:23
Message:
I'm running out of options... But it's working on bash-4.1 now, right? Then
maybe we can skip the unicode test for bash <= 3?
----------------------------------------------------------------------
Comment By: Ville Skyttä (scop-guest)
Date: 2010-10-21 00:00
Message:
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
$ LC_ALL=en_US.UTF-8 ./run --tool_exec ~/bin/bash-3.2.39 [...]
# Setting LC_ALL makes no difference
$ expect -v
expect version 5.43.0
$ tclsh
% info patchlevel
8.5.8
Patching test/config/bashrc and test/lib/library.exp with your suggested
changes make no difference either :(
----------------------------------------------------------------------
Comment By: Freddy Vulto (fvu-guest)
Date: 2010-10-20 23:49
Message:
From your dbg.log it looks like `expect' sends "f a\u00e9/\t" all right, but
either bash or `expect' drops the "\u00e9" on echoing/receiving:
send: sending "f a\u00e9/\t" to { exp7 }
expect: does "" (spawn_id exp7) match exact string "f a\u00e9/"? no
f a/
expect: does "f a/" (spawn_id exp7) match exact string "f a\u00e9/"? no
expect: timed out
This is similar to my initial findings on Debian, which now appears to be fixed
by not changing LC_CTYPE=C within a test run. Are you sure all locales as
reported by `locale' are set to "en_US.UTF-8"? Especially LC_CTYPE?
From http://www.infodrom.org/Debian/doc/maint/Maintenance-sysadmin.html I
understand setting LANG may cause already set LC_ variables to keep their
value. What happens if you set LC_ALL instead of LANG:
LC_ALL=en_US.UTF-8 ./run unit/_filedir.exp
What version of `expect' (expect -v) and `tcl' (tclsh, info patchlevel) are you
using, just in case?
Another useful page: http://www.in-ulm.de/~mascheck/locale/
What happens if you patch test/config/bashrc like this, just so we can at least
get it to work once on your machine:
@@ -23,6 +23,9 @@ stty columns 150
# installed via the same PATH expansion in `bash_completion.have()'
export PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin
+export LANG=en_US.UTF-8
+export LC_ALL=en_US.UTF-8
+
# Make sure default settings are in effect
unset -v \
COMP_CONFIGURE_HINTS \
If that doesn't work, maybe this patch in test/lib/library.exp:
@@ -132,6 +132,7 @@ proc assert_complete {expected cmd {test ""} {prompt
/@} {size 20} {cword ""} {f
} else {
if {$test == ""} {set test "$cmd should show completions"}
send "$cmd\t"
+ sleep .01
if {[llength $expected] == 1} {
expect -ex "$cmd"
----------------------------------------------------------------------
Comment By: Ville Skyttä (scop-guest)
Date: 2010-10-20 19:03
Message:
Attached is the part of my dbg.log from the previous PASS to the two FAILs for
_filedir.exp. This is with bash-3.2.39 and UTF-8 locale settings.
----------------------------------------------------------------------
Comment By: Freddy Vulto (fvu-guest)
Date: 2010-10-19 23:51
Message:
Hmm, and on another Ubuntu-10.04 this test is giving me a segmentation fault
right after the aé test seemed to have passed... Can you run the test with
--debug and send the part of dbg.log where the test fails?
----------------------------------------------------------------------
Comment By: Ville Skyttä (scop-guest)
Date: 2010-10-19 00:14
Message:
Unfortunately that change does not appear to make any difference here; it
behaves just like before it (fails with en_US.UTF-8 with both bash 3.2.25 and
3.2.39, works with 4.1.7).
----------------------------------------------------------------------
Comment By: Freddy Vulto (fvu-guest)
Date: 2010-10-18 23:31
Message:
I'm having troubles with `expect': changing the locale within an `expect'
session causes bash to exit, although I had it working before. The problem
occurs only on an old Debian system though, not on a newer Ubuntu system...
Steps to reproduce the problem:
1. Create a file unicode.exp containing:
spawn bash
send "LC_CTYPE=C\r"
send "aaébb"; # unicode é = \u00e9
expect -ex "cc"; # 'expect' detects eof when reading \u00e9?
send "dd"; # 'expect' error: spawn id not open
2. Run: LC_CTYPE=en_US.UTF-8 expect -f unicode.exp
3. I get this error output:
$ expect -f unicode.exp
spawn bash
LC_CTYPE=C
aaébb$ LC_CTYPE=C
$ aasend: spawn id exp6 not open
while executing
"send "dd""
(file "unicode.exp" line 6)
4. What I expected is the same output as with LC_CTYPE=C expect -f unicode.exp:
$ LC_CTYPE=C expect -f unicode.exp
spawn bash
LC_CTYPE=C
aaébb$ LC_CTYPE=C
$ aaC)bb$
See also:
http://fvue.nl/wiki/Expect:_Changing_locale_causes_spawned_process_to_exit
So it looks like changing LC_CTYPE within `expect' wasn't such a good idea.
For now I'll put the _filedir test ("completing f aé should return g") behind
the condition that LC_CTYPE should match *UTF-8*, otherwise the following run
definitely fails:
$ LC_CTYPE=C ./run unit/_filedir.exp
See commit 37f51b9.
Greetings,
Freddy Vulto
http://fvue.nl
----------------------------------------------------------------------
Comment By: Freddy Vulto (fvu-guest)
Date: 2010-10-11 23:13
Message:
Don't know what's going on. I get your errors when running from cron. But
when running manual with locale set to "en_US.UTF-8", tcl/expect/dejagnu chokes
on the unicode char, from dbg.log:
send: sending "f a\u00e9/\t" to { exp9 }
expect: does "" (spawn_id exp9) match exact string "f a\u00e9/"? no
f
expect: does "f" (spawn_id exp9) match exact string "f a\u00e9/"? no
expect: does "f " (spawn_id exp9) match exact string "f a\u00e9/"? no
a
expect: does "f a" (spawn_id exp9) match exact string "f a\u00e9/"? no
expect: read eof
expect: set expect_out(spawn_id) "exp9"
expect: set expect_out(buffer) "f a"
write() failed to write anything - will sleep(1) and retry...
ERROR: tcl error sourcing ./unit/_filedir.exp.
ERROR: expect: spawn id exp9 not open
----------------------------------------------------------------------
Comment By: Ville Skyttä (scop-guest)
Date: 2010-10-10 11:53
Message:
It also fails the same way for me with bash 3.2.25 and 3.2.39, no matter what
LANG is set to.
----------------------------------------------------------------------
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=312477&group_id=100114
_______________________________________________
Bash-completion-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
