Bash: keybinding/trap issue

Question

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?

Answer 1

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
4.1.5(1)-release
bash-4.1$ bind -x '"\037":echo foo;'
bash-4.1$ trap '$()' DEBUG
foo
bash-4.1$ echo bar
bash: bar: command not found

bash-4.1$

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.

Answer 2

Put this in your ~/.inputrc::

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