Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
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
add comment

2 Answers 2

up vote 0 down vote accepted

Put this in your ~/.inputrc::

"\M-l":    "ls -ltrF\r"
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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