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.

migrated from stackoverflow.com Nov 4 '13 at 5:08

This question came from our site for professional and enthusiast programmers.

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.)

  • 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 Oct 27 '13 at 16:59
  • Maybe you have to restart bash before it will notice that change? Try opening a new terminal. – Robin Green Oct 27 '13 at 17:03
  • Thanks for the further tip. Still no luck, unfortunately. – guypursey Oct 27 '13 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>
  • 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 Nov 7 '13 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/… – Moreaki Nov 7 '13 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.