diff --git a/CHANGES b/CHANGES index 620fa6f3..7de6a609 100644 --- a/CHANGES +++ b/CHANGES @@ -143,6 +143,9 @@ bash-completion (1.x) * Patched _known_hosts() to support multiple {Global,User}KnownHosts in SSH config files, thanks to Thomas Nilsson (Alioth: #311595) (Debian: #524190) * Fix leaking $i from info, man and python completions. + * Added setting COMP_KNOWN_HOSTS_WITH_HOSTFILE. _known_hosts_real() will add + hosts from HOSTFILE, unless COMP_KNOWN_HOSTS_WITH_HOSTFILE is set to an + empty value (Alioth: #311821) -- David Paleino Thu, 18 Jun 2009 13:12:36 +0200 diff --git a/bash_completion b/bash_completion index ef345105..ec4e070f 100644 --- a/bash_completion +++ b/bash_completion @@ -1214,16 +1214,16 @@ _known_hosts_real() fi fi - # Now add results of normal hostname completion - COMPREPLY=( "${COMPREPLY[@]}" $( compgen -A hostname -- $cur ) ) - # apply suffix and prefix for (( i=0; i < ${#COMPREPLY[@]}; i++ )); do COMPREPLY[i]=$prefix$user${COMPREPLY[i]}$suffix done - elif [ -z "$configfile" ]; then - # Just do normal hostname completion - COMPREPLY=( $( compgen -A hostname -S "$suffix" -- $cur ) ) + fi + + # Add results of normal hostname completion, unless `COMP_KNOWN_HOSTS_WITH_HOSTFILE' + # is set to an empty value. + if [ -n "${COMP_KNOWN_HOSTS_WITH_HOSTFILE-1}" ]; then + COMPREPLY=( "${COMPREPLY[@]}" $( compgen -A hostname -P "$prefix$user" -S "$suffix" -- $cur ) ) fi return 0 diff --git a/doc/bash_completion.txt b/doc/bash_completion.txt new file mode 100644 index 00000000..c7e7a2b9 --- /dev/null +++ b/doc/bash_completion.txt @@ -0,0 +1,34 @@ +Bash completion +=============== + +Environment variables +--------------------- + +*COMP_CONFIGURE_HINTS*:: + If set and not null, `configure` completion will return the entire option + string (e.g. `--this-option=DESCRIPTION`) so one can see what kind of data + is required and then simply delete the descriptive text and add one's own + data. If unset or null (default), `configure` completion will strip + everything after the '=' when returning completions. + + +*COMP_CVS_REMOTE*:: + If set and not null, `cvs commit` completion will try to complete on + remotely checked-out files. This requires passwordless access to the + remote repository. Default is unset. + + +*COMP_KNOWN_HOSTS_WITH_HOSTFILE*:: + If set and not null (default), known_hosts completion will complement + hostnames from ssh's known_hosts_files with hostnames taken from the file + specified by the HOSTFILE shell variable (compgen -A hostname). If null, + known_hosts completion will omit hostnames from HOSTFILE. Omitting + hostnames from HOSTFILE is useful if HOSTFILE contains many entries for + local web development or ad-blocking. + + +*COMP_TAR_INTERNAL_PATHS*:: + If set and not null *before* sourcing bash_completion, `tar` completion + will do correct path completion for tar file contents. If unset or null, + `tar' completion will do correct completion for paths to tar files. See + also README. diff --git a/doc/html~/main.html b/doc/html~/main.html index adbd0c51..86ce6d81 100644 --- a/doc/html~/main.html +++ b/doc/html~/main.html @@ -1,9 +1,39 @@ -Bash-completion

Bash-completion

Freddy Vulto (FVu)

Revision History
Revision 1.0Mar 2009FV(

Table of Contents

Preface
I. Coding Style Guide
1. Introduction
II. Automated testing
2. Introduction
3. Installing DejaGnu
3.1. Debian/Ubuntu
4. Structure
4.1. Main areas (DejaGnu tools)
4.2. Running the tests
5. Maintenance
5.1. Adding a completion test
5.2. Fixing a completion test
5.3. Fixing a unit test
6. Rationale
6.1. Naming conventions
6.1.1. Test suite or testsuite
6.1.2. script/generate
7. Reference
8. Test context
8.1. What happens when tests are run?
8.1.1. completion
8.1.2. install
8.1.3. unit
8.2. bashrc
8.3. inputrc
Index

List of Examples

8.1. What happens when completion tests are run?
8.2. What happens when install tests are run?
8.3. What happens when unit tests are run?

Preface

Bash completion extends bashs standard completion behavior to achieve +Bash-completion

Bash-completion

Freddy Vulto (FVu)

Revision History
Revision 1.0Mar 2009FV(

Table of Contents

Preface
I. Bash completion
1. Environment variables
II. Coding Style Guide
2. Introduction
III. Automated testing
3. Introduction
4. Installing DejaGnu
4.1. Debian/Ubuntu
5. Structure
5.1. Main areas (DejaGnu tools)
5.2. Running the tests
6. Maintenance
6.1. Adding a completion test
6.2. Fixing a completion test
6.3. Fixing a unit test
7. Rationale
7.1. Naming conventions
7.1.1. Test suite or testsuite
7.1.2. script/generate
8. Reference
9. Test context
9.1. What happens when tests are run?
9.1.1. completion
9.1.2. install
9.1.3. unit
9.2. bashrc
9.3. inputrc
Index

List of Examples

9.1. What happens when completion tests are run?
9.2. What happens when install tests are run?
9.3. What happens when unit tests are run?

Preface

Bash completion extends bashs standard completion behavior to achieve complex command lines with just a few keystrokes. This project was conceived to produce programmable completion routines for the most common Linux/UNIX commands, reducing the amount of typing sysadmins -and programmers need to do on a daily basis.

Part I. Coding Style Guide

Table of Contents

1. Introduction

Chapter 1. Introduction

This document attempts to explain the basic styles and patterns that are used in the bash completion. New code should try to conform to these standards so that it is as easy to maintain as existing code. Of course every rule has an exception, but it's important to know the rules nonetheless!

This is particularly directed at people new to the bash completion codebase, who are in the process of getting their code reviewed. Before getting a review, please read over this document and make sure your code conforms to the recommendations here.

Part II. Automated testing

Table of Contents

2. Introduction
3. Installing DejaGnu
3.1. Debian/Ubuntu
4. Structure
4.1. Main areas (DejaGnu tools)
4.2. Running the tests
5. Maintenance
5.1. Adding a completion test
5.2. Fixing a completion test
5.3. Fixing a unit test
6. Rationale
6.1. Naming conventions
6.1.1. Test suite or testsuite
6.1.2. script/generate
7. Reference
8. Test context
8.1. What happens when tests are run?
8.1.1. completion
8.1.2. install
8.1.3. unit
8.2. bashrc
8.3. inputrc

Chapter 2. Introduction

The bash-completion package contains an automated test suite. Running the tests should help verifying that bash-completion works as expected. The tests are also very helpful in uncovering software regressions at an early stage.

The bash-completion test suite is written on top of the DejaGnu testing framework. DejaGnu is written in Expect, which in turn uses Tcl — Tool command language.

Chapter 3. Installing DejaGnu

Table of Contents

3.1. Debian/Ubuntu

Installing DejaGnu should be easy using your local package manager.

3.1. Debian/Ubuntu

On Debian/Ubuntu you can use apt-get:

sudo apt-get install dejagnu

This should also install the necessary expect and tcl packages.

Chapter 4. Structure

Table of Contents

4.1. Main areas (DejaGnu tools)
4.2. Running the tests

4.1. Main areas (DejaGnu tools)

The tests are grouped into different areas, called tool in DejaGnu:

+and programmers need to do on a daily basis.

Part I. Bash completion

Table of Contents

1. Environment variables

Chapter 1. Environment variables

+COMP_CONFIGURE_HINTS +
+ If set and not null, configure completion will return the entire option + string (e.g. --this-option=DESCRIPTION) so one can see what kind of data + is required and then simply delete the descriptive text and add one’s own + data. If unset or null (default), configure completion will strip + everything after the = when returning completions. +
+COMP_CVS_REMOTE +
+ If set and not null, cvs commit completion will try to complete on + remotely checked-out files. This requires passwordless access to the + remote repository. Default is unset. +
+COMP_KNOWN_HOSTS_WITH_HOSTFILE +
+ If set and not null (default), known_hosts completion will complement + hostnames from ssh’s known_hosts_files with hostnames taken from the file + specified by the HOSTFILE shell variable (compgen -A hostname). If null, + known_hosts completion will omit hostnames from HOSTFILE. Omitting + hostnames from HOSTFILE is useful if HOSTFILE contains many entries for + local web development or ad-blocking. +
+COMP_TAR_INTERNAL_PATHS +
+ If set and not null before sourcing bash_completion, ‘tar` completion + will do correct path completion for tar file contents. If unset or null, + `tar’ completion will do correct completion for paths to tar files. See + also README. +

Part II. Coding Style Guide

Table of Contents

2. Introduction

Chapter 2. Introduction

This document attempts to explain the basic styles and patterns that are used in the bash completion. New code should try to conform to these standards so that it is as easy to maintain as existing code. Of course every rule has an exception, but it’s important to know the rules nonetheless!

This is particularly directed at people new to the bash completion codebase, who are in the process of getting their code reviewed. Before getting a review, please read over this document and make sure your code conforms to the recommendations here.

Part III. Automated testing

Table of Contents

3. Introduction
4. Installing DejaGnu
4.1. Debian/Ubuntu
5. Structure
5.1. Main areas (DejaGnu tools)
5.2. Running the tests
6. Maintenance
6.1. Adding a completion test
6.2. Fixing a completion test
6.3. Fixing a unit test
7. Rationale
7.1. Naming conventions
7.1.1. Test suite or testsuite
7.1.2. script/generate
8. Reference
9. Test context
9.1. What happens when tests are run?
9.1.1. completion
9.1.2. install
9.1.3. unit
9.2. bashrc
9.3. inputrc

Chapter 3. Introduction

The bash-completion package contains an automated test suite. Running the tests should help verifying that bash-completion works as expected. The tests are also very helpful in uncovering software regressions at an early stage.

The bash-completion test suite is written on top of the DejaGnu testing framework. DejaGnu is written in Expect, which in turn uses Tcl — Tool command language.

Chapter 4. Installing DejaGnu

Table of Contents

4.1. Debian/Ubuntu

Installing DejaGnu should be easy using your local package manager.

4.1. Debian/Ubuntu

On Debian/Ubuntu you can use apt-get:

sudo apt-get install dejagnu

This should also install the necessary expect and tcl packages.

Chapter 5. Structure

Table of Contents

5.1. Main areas (DejaGnu tools)
5.2. Running the tests

5.1. Main areas (DejaGnu tools)

The tests are grouped into different areas, called tool in DejaGnu:

completion
Functional tests per completion. @@ -15,11 +45,11 @@ and programmers need to do on a daily basis.

unit
Unit tests for bash-completion helper functions. -

Each tool has a slightly different way of loading the test fixtures, see Test context below.

4.2. Running the tests

The tests are run by calling runtest in the test directory:

runtest --outdir log --tool completion
+

Each tool has a slightly different way of loading the test fixtures, see Test context below.

5.2. Running the tests

The tests are run by calling runtest in the test directory:

runtest --outdir log --tool completion
 runtest --outdir log --tool install
 runtest --outdir log --tool unit

The commands above are already wrapped up in shell scripts within the test directory:

./runCompletion
 ./runInstall
-./runUnit

Chapter 5. Maintenance

Table of Contents

5.1. Adding a completion test
5.2. Fixing a completion test
5.3. Fixing a unit test

5.1. Adding a completion test

You can add script/generate to add a test.

5.2. Fixing a completion test

Let's consider this real-life example where an ssh completion bug is fixed. First you're triggered by unsuccessful tests:

$ ./runCompletion
+./runUnit

Chapter 6. Maintenance

Table of Contents

6.1. Adding a completion test
6.2. Fixing a completion test
6.3. Fixing a unit test

6.1. Adding a completion test

You can run cd test && ./generate to add a test.

6.2. Fixing a completion test

Let’s consider this real-life example where an ssh completion bug is fixed. First you’re triggered by unsuccessful tests:

$ ./runCompletion
 ...
                 === completion Summary ===
 
@@ -28,41 +58,41 @@ runtest --outdir log --tool unit

The commands above are already wrapped # of unresolved testcases 2 # of unsupported tests 47

Take a look in log/completion.log to find out which specific command is failing.

$ vi log/completion.log

Search for UNRESOLVED or FAIL. From there scroll up to see which .exp test is failing:

/@Running ./completion/ssh.exp ...
 ...
-UNRESOLVED: Tab should complete ssh known-hosts at prompt

In this case it appears ssh.exp is causing the problem. Isolate the ssh tests by specifying just ssh.exp to run. Furthermore add the —debug flag, so output gets logged in dbg.log:

$ ./runCompletion ssh.exp --debug
+UNRESOLVED: Tab should complete ssh known-hosts at prompt

In this case it appears ssh.exp is causing the problem. Isolate the ssh tests by specifying just ssh.exp to run. Furthermore add the --debug flag, so output gets logged in dbg.log:

$ ./runCompletion ssh.exp --debug
 ...
                 === completion Summary ===
 
 # of expected passes            1
-# of unresolved testcases       1

Now we can have a detailed look in dbg.log to find out what's going wrong. Open dbg.log and search for UNRESOLVED (or FAIL if that's what you're looking for):

UNRESOLVED: Tab should complete ssh known-hosts at prompt

From there, search up for the first line saying:

expect: does "..." match regular expression "..."

This tells you where the actual output differs from the expected output. In this case it looks like the test "ssh -F fixtures/ssh/config <TAB>" is expecting just hostnames, whereas the actual completion is containing commands - but no hostnames. -So what should be expected after "ssh -F fixtures/ssh/config <TAB>" are both commands and hostnames. This means both the test and the completion need fixing. Let's start with the test.

$ vi lib/completions/ssh.exp

Search for the test "Tab should complete ssh known-hosts". Here you could've seen that what was expected were hostnames ($hosts):

set expected "^$cmd\r\n$hosts\r\n/@$cmd$"

Adding all commands (which could well be over 2000) to expected, seems a bit overdone so we're gonna change things here. Lets expect the unit test for _known_hosts assures all hosts are returned. Then all we need to do here is expect one host and one command, just to be kind of sure that both hosts and commands are completed.

Looking in the fixture for ssh:

$ vi fixtures/ssh/known_hosts

it looks like we can add an additional host ls_known_host. Now if we would perform the test "ssh -F fixtures/ssh/config ls<TAB>" both the command ls and the host ls_known_host should come up. Let's modify the test so:

$ vi lib/completions/ssh.exp
+# of unresolved testcases       1

Now we can have a detailed look in dbg.log to find out what’s going wrong. Open dbg.log and search for UNRESOLVED (or FAIL if that’s what you’re looking for):

UNRESOLVED: Tab should complete ssh known-hosts at prompt

From there, search up for the first line saying:

expect: does "..." match regular expression "..."

This tells you where the actual output differs from the expected output. In this case it looks like the test "ssh -F fixtures/ssh/config <TAB>" is expecting just hostnames, whereas the actual completion is containing commands - but no hostnames. +So what should be expected after "ssh -F fixtures/ssh/config <TAB>" are both commands and hostnames. This means both the test and the completion need fixing. Let’s start with the test.

$ vi lib/completions/ssh.exp

Search for the test "Tab should complete ssh known-hosts". Here you could’ve seen that what was expected were hostnames ($hosts):

set expected "^$cmd\r\n$hosts\r\n/@$cmd$"

Adding all commands (which could well be over 2000) to expected, seems a bit overdone so we’re gonna change things here. Lets expect the unit test for _known_hosts assures all hosts are returned. Then all we need to do here is expect one host and one command, just to be kind of sure that both hosts and commands are completed.

Looking in the fixture for ssh:

$ vi fixtures/ssh/known_hosts

it looks like we can add an additional host ls_known_host. Now if we would perform the test "ssh -F fixtures/ssh/config ls<TAB>" both the command ls and the host ls_known_host should come up. Let’s modify the test so:

$ vi lib/completions/ssh.exp
 ...
 set expected "^$cmd\r\n.*ls.*ls_known_host.*\r\n/@$cmd$"

Running the test reveals we still have an unresolved test:

$ ./runCompletion ssh.exp --debug
 ...
                 === completion Summary ===
 
 # of expected passes            1
-# of unresolved testcases       1

But if now look into the log file dbg.log we can see the completion only returns commands starting with ls but fails to match our regular expression which also expects the hostname `ls_known_host':

$ vi dbg.log
+# of unresolved testcases       1

But if now look into the log file ‘dbg.log` we can see the completion only returns commands starting with ls but fails to match our regular expression which also expects the hostname `ls_known_host’:

$ vi dbg.log
 ...
-expect: does "ssh -F fixtures/ssh/config ls\r\nls           lsattr       lsb_release  lshal        lshw         lsmod        lsof         lspci        lspcmcia     lspgpot      lss16toppm\r\nlsusb\r\n/@ssh -F fixtures/ssh/config ls" (spawn_id exp9) match regular expression "^ssh -F fixtures/ssh/config ls\r\n.*ls.*ls_known_host.*\r\n/@ssh -F fixtures/ssh/config ls$"? no

Now let's fix ssh completion:

$ vi ../contrib/ssh
+expect: does "ssh -F fixtures/ssh/config ls\r\nls           lsattr       lsb_release  lshal        lshw         lsmod        lsof         lspci        lspcmcia     lspgpot      lss16toppm\r\nlsusb\r\n/@ssh -F fixtures/ssh/config ls" (spawn_id exp9) match regular expression "^ssh -F fixtures/ssh/config ls\r\n.*ls.*ls_known_host.*\r\n/@ssh -F fixtures/ssh/config ls$"? no

Now let’s fix ssh completion:

$ vi ../contrib/ssh
 ...

until the test shows:

$ ./runCompletion ssh.exp
 ...
                 === completion Summary ===
 
-# of expected passes            2

5.3. Fixing a unit test

Now let's consider a unit test failure. First you're triggered by unsuccessful tests:

$ ./runUnit
+# of expected passes            2

6.3. Fixing a unit test

Now let’s consider a unit test failure. First you’re triggered by unsuccessful tests:

$ ./runUnit
 ...
                 === unit Summary ===
 
 # of expected passes            1
 # of unexpected failures        1

Take a look in log/unit.log to find out which specific command is failing.

$ vi log/unit.log

Search for UNRESOLVED or FAIL. From there scroll up to see which .exp test is failing:

/@Running ./unit/_known_hosts_real.exp ...
 ...
-FAIL: Environment should stay clean

In this case it appears _known_hosts_real.exp is causing the problem. Isolate the _known_hosts_real test by specifying just _known_hosts_real.exp to run. Furthermore add the —debug flag, so output gets logged in dbg.log:

$ ./runUnit _known_hosts_real.exp --debug
+FAIL: Environment should stay clean

In this case it appears _known_hosts_real.exp is causing the problem. Isolate the _known_hosts_real test by specifying just _known_hosts_real.exp to run. Furthermore add the --debug flag, so output gets logged in dbg.log:

$ ./runUnit _known_hosts_real.exp --debug
 ...
                 === completion Summary ===
 
 # of expected passes            1
-# of unexpected failures        1

Now, if we haven't already figured out the problem, we can have a detailed look in dbg.log to find out what's going wrong. Open dbg.log and search for UNRESOLVED (or FAIL if that's what you're looking for):

FAIL: Environment should stay clean

From there, search up for the first line saying:

expect: does "..." match regular expression "..."

This tells you where the actual output differs from the expected output. In this case it looks like the the function _known_hosts_real is unexpectedly modifying global variables cur and flag. In case you need to modify the test:

$ vi lib/unit/_known_hosts_real.exp

Chapter 6. Rationale

Table of Contents

6.1. Naming conventions
6.1.1. Test suite or testsuite
6.1.2. script/generate

6.1. Naming conventions

6.1.1. Test suite or testsuite

The primary Wikipedia page is called -test suite and not testsuite, so that's what this -document sticks to.

6.1.2. script/generate

The name and location of this code generation script come from Ruby on Rails' script/generate.

Chapter 7. Reference

Within test scripts the following library functions can be used:

Chapter 8. Test context

Table of Contents

8.1. What happens when tests are run?
8.1.1. completion
8.1.2. install
8.1.3. unit
8.2. bashrc
8.3. inputrc

The test environment needs to be put to fixed states when testing. For instance the bash prompt (PS1) is set to the current test directory, followed by an ampersand (@). The default settings for bash reside in config/bashrc and config/inputrc.

For each tool (completion, install, unit) a slightly different context is in effect.

8.1. What happens when tests are run?

8.1.1. completion

When the completions are tested, invoking DejaGnu will result in a call to completion_start() which in turn will start bash —rcfile config/bashrc.

Example 8.1. What happens when completion tests are run?

               | runtest --tool completion
+# of unexpected failures        1

Now, if we haven’t already figured out the problem, we can have a detailed look in dbg.log to find out what’s going wrong. Open dbg.log and search for UNRESOLVED (or FAIL if that’s what you’re looking for):

FAIL: Environment should stay clean

From there, search up for the first line saying:

expect: does "..." match regular expression "..."

This tells you where the actual output differs from the expected output. In this case it looks like the the function _known_hosts_real is unexpectedly modifying global variables cur and flag. In case you need to modify the test:

$ vi lib/unit/_known_hosts_real.exp

Chapter 7. Rationale

Table of Contents

7.1. Naming conventions
7.1.1. Test suite or testsuite
7.1.2. script/generate

7.1. Naming conventions

7.1.1. Test suite or testsuite

The primary Wikipedia page is called +test suite and not testsuite, so that’s what this +document sticks to.

7.1.2. script/generate

The name and location of this code generation script come from Ruby on Rails' script/generate.

Chapter 8. Reference

Within test scripts the following library functions can be used:

Chapter 9. Test context

Table of Contents

9.1. What happens when tests are run?
9.1.1. completion
9.1.2. install
9.1.3. unit
9.2. bashrc
9.3. inputrc

The test environment needs to be put to fixed states when testing. For instance the bash prompt (PS1) is set to the current test directory, followed by an ampersand (@). The default settings for bash reside in config/bashrc and config/inputrc.

For each tool (completion, install, unit) a slightly different context is in effect.

9.1. What happens when tests are run?

9.1.1. completion

When the completions are tested, invoking DejaGnu will result in a call to completion_start() which in turn will start bash --rcfile config/bashrc.

Example 9.1. What happens when completion tests are run?

               | runtest --tool completion
                V
     +----------+-----------+
     |  lib/completion.exp  |
@@ -87,7 +117,7 @@ document sticks to.

Setting up bash once within completion_start() has the speed advantage that bash - and bash-completion - need only initialize once when testing multiple completions, e.g.:

    runtest --tool completion alias.exp cd.exp

8.1.2. install

Example 8.2. What happens when install tests are run?

                 | runtest --tool install
+    +----------------------+

Setting up bash once within completion_start() has the speed advantage that bash - and bash-completion - need only initialize once when testing multiple completions, e.g.:

    runtest --tool completion alias.exp cd.exp

9.1.2. install

Example 9.2. What happens when install tests are run?

                 | runtest --tool install
                  V
             +----+----+
             | DejaGnu |
@@ -101,7 +131,7 @@ document sticks to.

8.1.3. unit

Example 8.3. What happens when unit tests are run?

               | runtest --tool unit
+    +-------------------------+

9.1.3. unit

Example 9.3. What happens when unit tests are run?

               | runtest --tool unit
                V
           +----+----+
           | DejaGnu |
@@ -111,8 +141,7 @@ document sticks to.

8.2. bashrc

This is the bash configuration file (bashrc) used for testing:

-# -*- mode: shell-script; sh-basic-offset: 8; indent-tabs-mode: t -*-
+    +----------------------+

9.2. bashrc

This is the bash configuration file (bashrc) used for testing:

# -*- mode: shell-script; sh-basic-offset: 8; indent-tabs-mode: t -*-
 # ex: ts=8 sw=8 noet filetype=sh
 #
 # bashrc file for DejaGnu testsuite
@@ -134,9 +163,15 @@ export INPUTRC=$TESTDIR/config/inputrc
         # Ensure enough columns so expect doesn't have to care about line breaks
 stty columns 150
 
-. lib/library.sh
-

8.3. inputrc

This is the readline configuration file (inputrc) used for testing:

-# -*- mode: shell-script; sh-basic-offset: 8; indent-tabs-mode: t -*-
+        # Make sure default settings are in effect
+unset -v \
+    COMP_CONFIGURE_HINTS \
+    COMP_CVS_REMOTE \
+    COMP_KNOWN_HOSTS_WITH_HOSTFILE \
+    COMP_TAR_INTERNAL_PATHS
+
+        # Load bash testsuite helper functions
+. lib/library.sh

9.3. inputrc

This is the readline configuration file (inputrc) used for testing:

# -*- mode: shell-script; sh-basic-offset: 8; indent-tabs-mode: t -*-
 # ex: ts=8 sw=8 noet filetype=sh
 #
 # Readline init file for DejaGnu testsuite
@@ -151,5 +186,4 @@ set completion-query-items -1
         # Display completions sorted horizontally, not vertically
 set print-completions-horizontally on
         # Don't use pager when showing completions
-set page-completions off
-

Index

+set page-completions off

Index

diff --git a/doc/main.txt b/doc/main.txt index d9cdd822..d8a3076a 100644 --- a/doc/main.txt +++ b/doc/main.txt @@ -12,7 +12,7 @@ common Linux/UNIX commands, reducing the amount of typing sysadmins and programmers need to do on a daily basis. // include::intro.txt[] -// include::bash_completion.txt[] +include::bash_completion.txt[] include::styleguide.txt[] include::testing.txt[] diff --git a/doc/makeHtml.sh b/doc/makeHtml.sh index 8e52eff3..ed29ab40 100755 --- a/doc/makeHtml.sh +++ b/doc/makeHtml.sh @@ -1,4 +1,4 @@ #!/bin/bash -eu [ -d html~ ] || mkdir html~ -a2x -D html~ -d book -f xhtml main.txt +a2x -D html~ -d book -f xhtml --unsafe main.txt diff --git a/doc/testing.txt b/doc/testing.txt index fe415973..8ebb29d3 100644 --- a/doc/testing.txt +++ b/doc/testing.txt @@ -72,7 +72,7 @@ Maintenance Adding a completion test ~~~~~~~~~~~~~~~~~~~~~~~~ -You can add script/generate to add a test. +You can run `cd test && ./generate` to add a test. Fixing a completion test diff --git a/test/config/bashrc b/test/config/bashrc index 7a50f6e4..85399773 100644 --- a/test/config/bashrc +++ b/test/config/bashrc @@ -20,4 +20,12 @@ export INPUTRC=$TESTDIR/config/inputrc # Ensure enough columns so expect doesn't have to care about line breaks stty columns 150 + # Make sure default settings are in effect +unset -v \ + COMP_CONFIGURE_HINTS \ + COMP_CVS_REMOTE \ + COMP_KNOWN_HOSTS_WITH_HOSTFILE \ + COMP_TAR_INTERNAL_PATHS + + # Load bash testsuite helper functions . lib/library.sh diff --git a/test/unit/_known_hosts_real.exp b/test/unit/_known_hosts_real.exp index a698b926..71966d5d 100644 --- a/test/unit/_known_hosts_real.exp +++ b/test/unit/_known_hosts_real.exp @@ -32,6 +32,32 @@ expect { sync_after_int +set test "Hosts should have username prefix and colon suffix" +set hosts [get_hosts] + # Hosts `gee', `hus' and `jar' are defined in ./fixtures/_known_hosts_real/config + # Hosts `doo' and `ike' are defined in ./fixtures/_known_hosts_real/known_hosts +lappend hosts doo gee hus ike jar +set hosts [lsort -ascii $hosts] +set expected {} +foreach host $hosts { + lappend expected "user@$host:" +}; # foreach +set expected [join $expected "\\s+"] + # Call _known_hosts +set cmd {_known_hosts_real -acF fixtures/_known_hosts_real/config 'user@'; echo_array COMPREPLY} +send "$cmd\r" +expect -ex "$cmd\r\n" +expect { + -re "^$expected\r\n/@$" { pass "$test" } + -re /@ { unresolved "$test at prompt" } + default { unresolved "$test" } +}; # expect + + +sync_after_int + + + set test "Config file containing space should work" set hosts [get_hosts] # Hosts `gee' and `hus' are defined in ./fixtures/_known_hosts_real/spaced conf @@ -51,6 +77,31 @@ expect { }; # expect +sync_after_int + + +set test "Empty COMP_KNOWN_HOSTS_WITH_HOSTFILE should omit HOSTFILE" +assert_bash_exec "COMP_KNOWN_HOSTS_WITH_HOSTFILE=" +set hosts {} + # Hosts `gee', `hus' and `jar' are defined in ./fixtures/_known_hosts_real/config + # Hosts `doo' and `ike' are defined in ./fixtures/_known_hosts_real/known_hosts +lappend hosts doo gee hus ike jar +set hosts [lsort -ascii $hosts] +set hosts [join $hosts "\\s+"] + # Call _known_hosts +set cmd {_known_hosts_real -aF fixtures/_known_hosts_real/config ''; echo_array COMPREPLY} +send "$cmd\r" +expect -ex "$cmd\r\n" +expect { + -re "^$hosts\r\n/@$" { pass "$test" } + -re /@ { unresolved "$test at prompt" } + default { unresolved "$test" } +}; # expect +sync_after_int +assert_bash_exec "unset -v COMP_KNOWN_HOSTS_WITH_HOSTFILE" + + + sync_after_int