Summary: | gnome-terminal-2.14* "looses" displayed text on reset and clear | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin Wegner <gentoo-bugs> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | ruud |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 119872 |
Description
Martin Wegner
2006-05-18 02:46:04 UTC
I don't see anything abnormal in any of the bash screens, what exactly is the problem here? Reset and clear does what it is supposed to to, it resets the terminal to the defaults and clears the screen, this includes clearing the prompt text. Hitting ctrl-c or enter should cause the shell to draw a new prompt. Also, I don't really know zsh, what is the expected behaviour and how does what happens differ? Ok, if that is the normal behaviour of reset and clear, ok. But this also happens ramdomly when any output of any other program in the gnome-terminal is done. For example, during an emerge process, text disappears in the same way. I get then the same as it can be seen on screenshot (3) for zsh, so you know there is an emerge process making much output, but no text is displayed. This happens also with ls, grep, ... The sad thing is that I cannot reproduce it. But it happens several times a day and therefore is very annoying ... You could run something in script(1) and maybe find out what the cause of the problem is. When I'm right, script just logs the commands, but I do not think, that it is caused by a specific command ... I just had this error again when I quit a "less <file>" (http://files.mgeek.de/Screenshot-error.png), the screenshot shows the terminal immediately after I hit Q. I tried to reproduce it with the same less call, but could't. I wonder if this maybe is related to zsh since I use Unicode but the latest version in portage may be not capable of unicode? script logs everything that is put to the screen, so it might let us see what is going on. zsh-4.3.2 support UTF-8, so you could use that one. But that probably isn't causing the problem since I've been using zsh+UTF-8 prior to that version. Hm, that's weird, zsh and unicode is _not_ working here for me. If I type several unicode chars: http://files.mgeek.de/Screenshot-unicode-0.png and the delete them, http://files.mgeek.de/Screenshot-unicode-1.png zle deletes charaktes equal to the number of bytes of the unicode chars: http://files.mgeek.de/Screenshot-unicode-2.png If I type many unicode chars, http://files.mgeek.de/Screenshot-unicode2-0.png multiline does not work and weird "question mark" charakters appear when first right prompt http://files.mgeek.de/Screenshot-unicode2-1.png and then the left prompt disappear, multiline displaying of the typed chars does not happen, they are displayed in the same line: http://files.mgeek.de/Screenshot-unicode2-2.png I think this issue is related to this behaviour, since for example multiline commands with unicode chars in them, are totally wrong displayed due to this ... Ah, sorry, I just remember that the disappearing of text in gnome-terminal also happened before I switched my system to unicode a few weeks ago. So I will log my sessions with script(1), the zsh/unicode problem seems to be not related although it would be nice if someone (for example Ruud) could take a look at this ... When I run script, I get an error: $ script log-20060524 Script started, file is log-20060524 zsh: No such file or directory and then script hangs. Also script -c /bin/zsh log-20060524 leads to the same error ... Sometimes the problem is located between computer and chair ;) The problem with Unicode is solved now, I still had LC_CTYPE="de_DE@euro" set, but it should be de_DE.utf8 . Now it works. But since I think the issue of this bug report is not related to the (now solved) unicode problem with my zsh, any hint how to get script(1) running is still welcome ... marking invalid as the issue was caused by setting an invalid locale. I disagree with marking invalid. As I stated above in comment #9 the problem with encoding is solved, yes, but it solved not the bug I originally described here. It was a side effect that I thought could be the reason for it. I'm still awaiting any response to my problem with script(1) described in comment #8, since I'm not able to provide the information requested in comment #3 and comment #5. I have not seen this bug for a longer time now. So I think it is somehow fixed for me. I'm not sure what resultion to set, so I leave it up to you. marking worksforme since reporter says he can no longer reproduce it. |