My .bashrc has the following:

# Alt+L lists current directory
bind -x "\"\el\":ls -ltrF --color=auto;"

# trap commands and echo them to xterm titlebar.
trap 'echo -ne "\033]0;$BASH_COMMAND - $USER@${HOSTNAME}>$(pwd)\007"' DEBUG

Demo of the problem:

bash-4.2$ [Alt+L] #works
total 0
-rw-rw-r--  1 me 1234 0 Aug  3 07:11 foo
-rw-rw-r--  1 me 1234 0 Aug  3 07:11 bar
bash-4.2$ ls -ltr #fails first time
bash: -ltr: command not found
bar  foo
bash-4.2$ ls -ltr #works second time
total 0
-rw-rw-r--  1 me 1234 0 Aug  3 07:11 foo
-rw-rw-r--  1 me 1234 0 Aug  3 07:11 bar

As you can see, the ls command fails the first time after executing the key binding. I believe it has to do with the trap. Removing the trap fixes the issue.

Is there any way to fix this without removing the trap?

  • What terminal program are you using? Have you tried the same in different ones (xterm especially)? Commented Aug 3, 2011 at 11:59
  • I'm using PuTTY. Don't have any others.
    – dogbane
    Commented Aug 3, 2011 at 12:01

2 Answers 2


I can reproduce this with a much smaller example. I tried in bash 4.1 from Debian squeeze and a bash 4.2.8(9) compiled from source.

% bash --norc
bash-4.1$ echo $BASH_VERSION
bash-4.1$ bind -x '"\037":echo foo;'
bash-4.1$ trap '$()' DEBUG
bash-4.1$ echo bar
bash: bar: command not found


I pressed Ctrl+_ (\037) immediately after the trap command returned. The command in the trap $() is an empty command producing empty output, thus a no-op. Command substitution seems to be the culprit, as nothing unexpected happens if I replace it by : or by a space.

I don't see how to explain a difference in behavior between $() and a space, so this looks like a bug. A cursory search on the bug-bash list didn't turn up anything.


Put this in your ~/.inputrc::

"\M-l":    "ls -ltrF\r"

You must log in to answer this question.

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