On 2011-11-16 15:51, Bastien Dejean wrote:

Hey,

I've added the following lines to my .bashrc:

case "$TERM" in rxvt*|xterm*) set -o functrace trap '[ -z "$BASH_SOURCE" ]&& printf "%b" "\e]0;$BASH_COMMAND\a"' DEBUG>& /dev/null ;; esac

(It sets the current title of the current window according to the last ran command.)

But alas, it generates side effects, if I issue this:

ls "$(ls -1 | head -1)"

I get:

ls: cannot access foo.bar: No such file or directory

Strange or trivial?

First, you are using `printf` the wrong way. Such sequences as \e]0; are supposed to be in the first argument, just like C printf(): printf "\e]0;%s\a" "$BASH_COMMAND" Your current method causes backslash escapes to be expanded not only in the literal \e and \a, but also in the value of $BASH_COMMAND; so, for example, if you ran this interactively: echo "\a is a bell" then your current `printf` command would receive: \e]0;echo "\a is a bell"\a which causes the title to be set to 'echo "', and the remainder text to be displayed normally (' is a bell"\a'). Second, your `ls` failure is caused by your `printf` output. It seems that the DEBUG trap handler is executed for subshells as well, with the trap handler's stdout being captured along with the actual command's stdout. In this case, $() will return your title-setting sequence. For example: echo "$(true)" > testfile Normally, 'testfile' would be blank, but in this case... You can sort of avoid this by redirecting the output to the proper location -- your terminal. (I'm not sure how reliable this is.) trap '[[ $BASH_SOURCE ]] || printf "\e]0;%s\a" "$BASH_COMMAND" >/dev/tty' DEBUG -- Mantas M.