FS#32821 - [bash] request for 'shopt -s checkwinsize' in /etc/bash.bashrc or /etc/skel/.bashrc

Attached to Project: Arch Linux
Opened by René Herman (rene) - Friday, 23 November 2012, 23:41 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Saturday, 10 December 2016, 18:55 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Resizing a terminal under X causes bash to mess up its output, most dramatically when using the history. Could we perhaps add "shopt -s checkwinsize" to the standard global or user-skeleton bashrc files? resizing (ie, maximizing) a terminal under X will be a very common thing, and it seems that now basically everyone needs to figure this out him- or herself.

I've personally added it conditionally on (being interactive and) the $DISPLAY variable existing -- and again for every system that I install -- and for every time that I do so... :-/

===
#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

[ ! -z $DISPLAY ] && shopt -s checkwinsize

...
===
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Saturday, 10 December 2016, 18:55 GMT
Reason for closing:  Fixed
Additional comments about closing:  bash 4.4.005-2
Comment by Dave Reisner (falconindy) - Friday, 23 November 2012, 23:51 GMT
Can you actually reproduce the problem with a prompt of PS1='\$ ' ?
Comment by René Herman (rene) - Saturday, 24 November 2012, 01:45 GMT
No, it seems I cannot at the moment. Which pisses me of immensely, since I run into this problem constantly on a fresh system when actually just using it...

I normally have a prompt of PS1='[\u@\h \w]\$ ' which means that depending on which directory I'm in, I can have a very long prompt. The usual situation is that I run of the right side of the screen while typing a long command and then experience the issue when recalling the command from the history and editing it at a later moment when the windows size has changed.

For example, maximized to non-maximized, when the long line is now spread over multiple lines, yet the cursor doesn't want to go past the LEFT edge of the terminal in order to edit the first part of the command (visually: I believe it actually does go back, but that I just can't see it).

Come to think of it -- that doesn't sound all that bash-related, although I'm quite sure that shopt -s checkwinsize does in fact solve it...

I'm using the XFCE "Terminal" terminal emulator. Is it screwing up?


Comment by Dave Reisner (falconindy) - Saturday, 24 November 2012, 01:50 GMT
Not a function of checkwinsize, which only updates LINES and COLUMNS after a command has been run. Sounds more like a terminal issue than a readline or bash issue, if I understand your explanation correctly.
Comment by René Herman (rene) - Saturday, 24 November 2012, 02:03 GMT
Yes, noticed as much as well while writing the previous comment. And yes, XFCE Terminal seems to be regularly messing up. Here's an old bug with respect to the same issue:

https://bugs.archlinux.org/task/16539

Since checkwinsize does have a performance drawback, I hereby withdraw the request. Anyone using the XFCE Terminal will still want it it seems -- but that's clearly not everyone.
Comment by CalimeroTeknik (Calimero) - Friday, 18 November 2016, 15:14 GMT
  • Field changed: Percent Complete (100% → 0%)
Using PS1='\$ ', in all terminals (tested xterm, urxvt and vte), this problem appears. Simply open an editor, resize the terminal emulator and close the editor. The problem appears.
I finally got around to pinpointing this long-running bug, and found this, therefore reopening.
The performance issue mentioned doesn't seem important. (bash updates the window size after each command completes)
Bug not present in zsh.
Comment by Dave Reisner (falconindy) - Friday, 18 November 2016, 15:16 GMT
Uggh, reopening a 4 year old bug... could you at least mention what version of bash this? If it's 4.4, does it behave the same with 4.3?
Comment by CalimeroTeknik (Calimero) - Friday, 18 November 2016, 15:20 GMT
I was getting this with bash 4.3 and now with 4.4 as well. (should I have opened a new bug? reporting guidelines don't mention that)
Comment by Bartłomiej Piotrowski (Barthalion) - Friday, 18 November 2016, 20:40 GMT
What are the steps to actually reproduce it? I can't see that "messed" output in GNOME terminal.
Comment by CalimeroTeknik (Calimero) - Friday, 18 November 2016, 21:44 GMT
For me, this is sufficient: "Simply open an editor, resize the terminal emulator and close the editor. The problem appears."
To check for the issue, I just press the ↑ key until a command is long enough to not hold on the line and wrap.
It will wrap as if the terminal had the size it had before the editor was started.

Here is a demo: https://oremilac.tk/bug-32821.ogv
Comment by Bartłomiej Piotrowski (Barthalion) - Thursday, 24 November 2016, 17:10 GMT
Okay, reproduced it. I'll add the checkwinsize option soon.

Loading...