xterm / bash weirdness?

September 21, 2011 2:24 PM

Weird Unix terminal issue where yer trying to up arrow through bash history and it looks messed up, right?

I don't know how to explain it. You open your Terminal app, and you do a really long command. Then you up arrow to repeat it but it doesn't.. uh.. display properly? Like, original command:

host> psql -h mydatabasehost -U myusername mydatabase -f somedamnfile.sql

Then you up arrow and you see

host> psqlpsql -h mydatabasehost -U myusername mydatabase -f somedamnfile.sql

Then you hit CTRL A to go to the beginning of the line and it goes to right after "host> psql".

Why? Am I making any sense? Is it an xterm thing? Is there a way to fix it? This has always bothered me, and my inability to properly describe it (as you see) has kept me from asking about it.

THANKS!

posted by xmutex to Computers & Internet (11 answers total)

This happens if you type in psql (or whatever) before going through your history with the arrow key or Ctrl-A combination.
posted by Blazecock Pileon at 2:38 PM on September 21, 2011

is it using libreadline ? Otherwise, I write that off usually as a display issue (since if you hit enter, the correct command is executed, ya ?)
posted by k5.user at 2:38 PM on September 21, 2011

Sorry, Ctrl-Y.
posted by Blazecock Pileon at 2:38 PM on September 21, 2011

Make your xterm wider and get to know Ctrl-L are the only two suggestions I can give.
posted by wierdo at 2:38 PM on September 21, 2011

Yeah, it's weirdness between interactions between readline, bash, and your terminal / pty. Introduce screen into the mix and things get even weirder.
posted by doteatop at 2:49 PM on September 21, 2011

What wierdo said. Ctrl-L will redraw the current line.
posted by zsazsa at 2:52 PM on September 21, 2011

I get this in tcsh too; the usual causes are wrapped lines and multibyte characters.
posted by nicwolff at 3:35 PM on September 21, 2011

Response by poster: Guess it's just one of those things. CTRL L is very handy though, thanks.
posted by xmutex at 6:08 PM on September 21, 2011

This is a symptom of having modified the prompt to include escape characters without using the proper sequences to tell readline that they are nonprinting.

Example: Wrong:

PS1='\e[33mfoobar\e[0m '

Readline looks at this variable and thinks your prompt is 16 characters long, so naturally it thinks you will be on column 17 when you start typing. But 9 of those characters are escape sequences, so you'd really be on column 8.

Right:

PS1='\[\e[33m\]foobar\[\e[0m\] '

The \[ and \] don't display, but they tell readline that everything in between them is an escape sequence that doesn't affect the cursor position, so it will correctly know that the cursor will be on column 8 after outputting this string.
posted by Rhomboid at 8:39 PM on September 21, 2011 [10 favorites]

This can also be caused by a sequence of non-printing characters, such as ANSI/VT100 escape sequences for colors, in your prompt. If you have such a thing make sure each sequence is surrounded by escaped brackets, as so: "\[...\]".
posted by metric space at 8:39 PM on September 21, 2011

I've had this exact same problem for 5+ years. My prompt is very simple, typically (imac) =. I never use anything other than ASCII, so it's not multi-byte characters. I tend to use bash on Linux and now MacOS and a variety of terminal emulators (PuTTY, SecureCRT, iTerm2) with TERM set to vt100 or xterm. Whatever the problem is, it's quite simple.

I don't have a solution. My own addition to the mix is it never happens when I leave my terminal window at 80 characters wide, only when I resize wider. My assumption has always been that libreadline doesn't hear the resize event and is doing something wrong with trying to redraw.
posted by Nelson at 9:48 AM on September 22, 2011 [1 favorite]