4

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)? – rozcietrzewiacz Aug 3 '11 at 11:59
  • I'm using PuTTY. Don't have any others. – dogbane Aug 3 '11 at 12:01
0

Put this in your ~/.inputrc::

"\M-l":    "ls -ltrF\r"
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.

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.