The -MFile::Sp and -MFile::Spec::Func test cases fail at the moment
but are not marked as expected failures, hoping for a quick fix for
the above bug ;)
File locations are prefixed with `$::srcdir' so that `make distcheck' can
execute the test suite using a relative path.
The current working directory is removed from the test-suite-bash-prompt.
Furthermore, no more dynamic creation of files in dir $::srcdir/fixtures since
this dir is read-only during `make distcheck'. Instead create dynamic files in
$TESTDIR/tmp
The test suite uses these "directory" variables
tcl bash description
------------ ----------- ------------------------------------
$::srcdir $SRCDIR where `fixtures' reside, relative
$::srcdirabs $SRCDIRABS where `fixtures' reside, absolute
$::TESTDIR $TESTDIR where `runtest' is invoked, absolute
completions, using an external helper just for functions and modules
completions. This is overally slower, as our helper outputs all available
modules at once, rather than just one piece of namespace, but this is
more in line with other completions
${tool}_start was called from within `config/default_exp', but this
proves to be error-prone, because DejaGnu isn't fully initialized at
that point, causing an error when calling one of the DejaGnu methods
pass/fail/unsupported/xfail/unresolved/untested:
can't read "multipass_name": no such variable
The right way seems to be calling ${tool}_start() from
${tool}_init().
Turn it on dynamically when needed instead; see doc/styleguide.txt for
a longer explanation. This fixes many non-filename completions which
had been previously more or less broken due to unwanted
escape-as-filenames behavior.
_usergroup now has a -u option, and there are new _allowed_users and
_allowed_groups helpers. These can be used to limit returned users
and/or groups to ones that the user has access to (or should be
assumed to have access to if running a "root command").
I had to remove a couple of "funky user" chown test cases because for
some reason they were broken by this change, I didn't immediately find
out why, and I couldn't come up with a valid use case that should be
supported for them that would be more beneficial than the relevance
improvements in this patch.
Steps to reproduce the problem:
$ LANG=POSIX ./run unit/_parse_help.exp
...
Running ./unit/_parse_help.exp ...
FAIL: short + long
FAIL: short + long, slash separated
Cause:
When comparing list items, `assert_bash_list()' expects the real list to be
sorted, whereas the output of `_parse_help' is unsorted.
These particular two tests were failing because they suffered the
following LANG-dependant sort-difference:
$ cat t.txt
-m
--n
$ LANG=en_US.UTF-8 sort t.txt
-m
--n
$ LANG=POSIX sort t.txt
--n
-m
Solution:
Made to default for `assert_bash_list' more-intuitive: unsorted, and added an
option `-sort' to explicitly enable sorting.
I felt uncomfortable adding yet another optional argument, so I seized this
opportunity to move subsequent optional arguments to single optional arguments.
E.g.:
assert_bash_list {expected cmd {test ""} {prompt /@} {size 20}} {
has now become:
# ...
# @param list $args Options:
# -nosort Compare list unsorted. Default is sorted
# -prompt Bash prompt. Default is `/@'
# -chunk-size N Compare list N items at a time. Default
# is 20.
assert_bash_list {expected cmd test {args {}}
(and the `test' argument has become mandatory).
This effectively turns off avahi-browse by default; doing it by
default is not worth it compared to the number of various (mostly
slowness) problems it has caused people, for example Alioth #312691
and RedHat #630326.
Mandriva has applied a similar patch for some time already, although
their environment variable name was different ($COMP_AVAHI_BROWSE).
