screen-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bash,TITLEBAR, and line wrapping


From: Ian A. Tegebo
Subject: bash,TITLEBAR, and line wrapping
Date: Sat, 22 Apr 2006 18:34:49 -0700
User-agent: Mutt/1.5.9i

I'm having line-wrapping problems.

I've set some bash variables to achieve titlebar and hardstatus
updating:

<code>
case $TERM in
xterm*)
    PROMPT_COMMAND='echo -ne "\033]0;address@hidden: ${PWD}\007"'
;;
screen*)
    PROMPT_COMMAND='echo -n -e "\033k\033\134"'
    TITLEBAR='\033]0;address@hidden   \w \007'
    PS1=${TITLEBAR}'\[\033[1;34m\][\!]\$ \[\033[0m\]' 
;;
esac
</code>

But now my terminal will prematurely wrap the line without issuing a
newline.  It does this once and then issues newlines and wraps correctly
afterwards.  So if I hold down a single key, say 'd', it will print
until the 59th column and then start over-writing my prompt.  Then it
goes until the actual end of the line before correctly going to the
start of the next line.

BTW, the 59th column happens when the terminal reports
---
$ stty size
24 80
---
and this appears correct to me.

My thought is that the way I'm setting PS1 is causing the terminal
to think the printed line is longer than it actually is.  This would
explain the wrapping but not the absence of a newline being printed.

I tried to confirm this by not setting TITLEBAR and found that the
behavior was not exhibited as predicted.

I've tried using another terminal, rxvt, by exporting the variable as
so:

<code, take from above>
;;
screen*)
    export TERM="rxvt"
    PROMPT_COMMAND='echo -n -e "\033k\033\134"'
<\code>

The result was no change.

I then wiped out my 'termcap/terminfo' lines in my .screenrc.  The
result was no change.

Here is some information:

It happens on both these versions of GNU bash:
        version 2.05b.0(1)-release (i386-pc-linux-gnu)
        version 3.1.17(1)-release (i686-pc-linux-gnu)

$ screen --version
Screen version 4.00.02 (FAU) 5-Dec-03

$ stty -a
speed 38400 baud; rows 23; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2
= M-^?;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
-ixoff
-iuclc ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt
echoctl echoke


I'm running this on Debian GNU/Linux.  A test on Gentoo GNU/Linux
produced similar results.  Testing on FreeBSD also produced the same
results.

BTW, the behavior at a specific column number changes as I resize the
X11 window I'm working in, e.g. maximizing the window causes the
premature wrap to happen at column #120 where

$ stty size
52 159

I see now that this, along with my previous report on the column number,
demonstrates that it is not a fixed number of columns that the error
occurs at.  I know that my TITLEBAR variable uses a directory name that
might affect this number, but I was sure to always be in $HOME while
doing these tests.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]