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.
