4

THE PROBLEM:

Say I'm trying to change to a directory called 'build' which is in the directory I'm currently in. I start:

cd b

Then I hit tab once (knowing that no other directories in the current one begins with the letter b). I expect to see the following, ready for me to hit return or change or augment as needed.

cd build

However, on my netbook which runs Linux Peppermint 3, I find that this appears when I press the tab button:

cd bbash: command substitution: line 74: syntax error near unexpected token `done'
bash: command substitution: line 74: `            done'

THINGS I'VE TRIED:

  • I've tried reinstalling the "bash-completion" package but this had no apparent effect.

  • I've looked at the file /etc/bash_completion and specifically at line 74 but I can see nothing obvious there that would need correcting (complete -f -X '*.Z' compress znew). Perhaps I am looking in the wrong file.

  • I find completion for commands like git, gedit, and node work okay. But trying to auto-complete a filename for kate also doesn't work.

  • When I ran bash -x for debugging, a lot of code was printed in the terminal and this was at the end (note the comment):

    + toks=(${toks[@]-} $(
        compgen -d -- "$quoted" | {
            while read -r tmp; do
                # TODO: I have removed a "[ -n $tmp ] &&" before 'printf ..',
                #       and everything works again. If this bug suddenly
                #       appears again (i.e. "cd /b<TAB>" becomes "cd /"),
                #       remember to check for other similar conditionals (here
                #       and _filedir_xspec()). --David
                printf '%s\n' $tmp
            done
        }
    ))
    bash: command substitution: line 74: syntax error near unexpected token `done'
    bash: command substitution: line 74: `            done'
    

    I tried adding the conditional mentioned back in but this had no effect.

  • I've tried temporarily removing etc/bash_completion.d but this had no effect.

  • I've tried complete -p to see a list of completions but I don't really know what I'm looking for.

A FINAL PLEA

I'm willing to get my hands dirty with the shell scripts if that's what takes; I can learn a bit more about this in the process. I really would it fixed though. Any suggestions appreciated.

2 Answers 2

1

Bash completion is modular; different packages provide their own completion extensions. Another package probably contains the bug. Try mv /etc/bash_completion.d{,.old} and see if that fixes it. If so, do mv /etc/bash_completion.d{.old,} to move it back again, and then move individual files out of the /etc/bash_completion.d directory one by one to identify the file that is causing the problem. (The directory might be called something slightly different on Peppermint.)

3
  • Thanks. I tried this but no joy. There is a directory called /etc/bash_completion.d in my instance of Peppermint and I was able to rename/move as you suggested but the problem remains as described.
    – guypursey
    Commented Oct 27, 2013 at 16:59
  • Maybe you have to restart bash before it will notice that change? Try opening a new terminal. Commented Oct 27, 2013 at 17:03
  • Thanks for the further tip. Still no luck, unfortunately.
    – guypursey
    Commented Oct 27, 2013 at 17:09
1

Can't officially comment yet, so I'll offer a partial answer pointing into another direction. Could you check your key bindings?

$ bind -p | grep -i tab

I have come across environments in the past where people had decided to bind the tab key with a functionality. The other option is to fork off a bash shell using the "-x" parameter, like so:

$ bash -x

Repeat your test. Does it happen as well if you use echo instead of cd?

$ echo b <tab>
2
  • Thanks for this. To answer your last question first, echo did not produce the same effect. The first command you gave returned # tab-insert (not bound). Forking the bash shell was interesting (never done that before). I repeated the test after the fork and got a long list of lines in return and in particular noticed this comment: # TODO: I have removed a "[ -n $tmp ] &&" before 'printf ..', # and everything works again. If this bug suddenly # appears again (i.e. "cd /b<TAB>" becomes "cd /"), # remember to check for other similar conditionals (here # and _filedir_xspec()). --David
    – guypursey
    Commented Nov 7, 2013 at 19:23
  • I suppose it has something to do with bash completion; my approach would be to check your defined completions using complete -p and remove the culprit using complete -r <culprit>. The other option is to disable it completely in the running shell using shopt -u progcomp. As you mentioned that you are running a Linux distro, which seems to be based on Ubuntu 13.04, I suppose other people will stumble across this type of error and it should be fixed in no time. Another option would be to reinstall bash completion: blog.onetechnical.com/2012/06/19/…
    – ikaerom
    Commented Nov 7, 2013 at 20:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .