I found an annoying bug while coloring the prompt of my Terminal. If I set my prompt to a colored one, such as
export PS1='\e[1;34m[\e[0;31m\D{%Hh%M} \e[0;32m\u\e[0m#\e[0;35m\h\e[0m:\e[0;36m\w\e[1;34m]\e[0m $ '
then it starts to break when I get some size in the input line:
In other words, when my line reaches some limit, it starts over itself! Once I fill the same line again, then it works well, going to the next line.
Have anyone seen this problem, too? Do you have a solution? The problem also happens in iTerm.
This is a duplicate of Mac Terminal.app annoying bug - How to fix it? from StackOverflow. The problem is that you must surround terminal control characters in square brackets \[ … \] so that the bash shell doesn't count them when calculating the length of the command prompt.
Since this is a generic shell/terminal question and not specific to Mac OS X or Terminal, this should probably be migrated to StackOverflow and made a duplicate of the other question. (However, I don't have privilege to do either.)
Related
Recently I've discovered a wonderful terminal multiplexing tool called gnu-screen.
I'm satisfied with it completely. But I've encountered one inconvenience I'd like to improve.
'C-a H' command makes screen log everything to a log file called named 'screenlog.*'.
But encodes control characters in a weird way. For example if you open the log file with 'less' you might see some cryptic characters and the log file is unreadable. You have to run 'less -r' or 'less --raw-control-chars' which helps to encode those control characters correctly.
So far so good. But if you want to edit the log or read it with vim then you encounter the same problem with control characters.
I've googled this problem and looked up at SO but I've been overwhelmed because there's so much info about vim and screen. Unfortunately I haven't found the solution yet.
Perhaps you know the solution for this problem or some workaround.
UPD
Thanks to Frédéric Hamidi's comment I discovered those characters are the terminal escape sequences of font color, etc. Vim as an editor sees them and by default edits them. The plugin Frédéric suggested tells vim to interpret them.
To provide an answer here and finally mark this fixed: The AnsiEsc plugin adds syntax highlighting for ANSI color sequences. So instead of seeing ^[[30m; the following text will be highlighting in the corresponding color, just like when using less --raw-control-chars.
sometimes in terminal when I type a long command, instead of continuing in the next line it starts to write at the same line and I cannot see what I am typing. What is the reason and how should I make it fine?
Sometimes if you resize a terminal window while in a fullscreen command (say inside "vim" or "less"), when you exit back to the shell it will assume your terminal has the old dimensions, and will show the behavior you are describing. See this question: https://unix.stackexchange.com/questions/61584/how-to-solve-the-issue-that-a-terminal-screen-is-messed-up-usually-after-a-res
Also, please in the future post this kind of questions in unix.stackexchange.com as this one is not strictly a programming question.
I have a random problem which I personally find quite irritating. I use the terminal alot and have installed a theme and even toyed around with what is displayed on the prompt. However if I write a particularly line of text it does not start a new line in the terminal instead it will begin overwriting what is displayed on the screen in the current terminal line. I wondered if anyone knew a way to solve this so that it does show a new line and all input would be visible.
PS1 value
export PS1="\r\n\e[1;32mdave:\w $\e[0;37m "
Well, thanks to the post by #Joni, I believe the solution is:
PS1="\r\n\[\e[1;32m\]dave:\w $\[\e[0;37m\] "
That is, here the color codes \e[1;32m and \e[0;37m are enclosed within \[ and \], as #Joni suggested they should be.
Non printing characters, like escape codes for color, have to be surrounded with \[ and \] so that bash knows to exclude them when calculating the length of the line.
http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html
When I'm typing a command longer than around 20 characters the text disappears and the cursor moves to a different location in the terminal. How do I stop this? I find it difficult to understand what I'm doing when this happens.
Your $PROMPT may have escape sequences in it that should be wrapped in %{...%} to keep them from being counted when zsh calculates the length of the displayed prompt.
There could be an incorrect TERM type, resulting in incorrect cursor positioning. For OS X Terminal.app, this term type works well for most curses-based apps:
$ echo $TERM
xterm-color
It should also work well in xterm.
Does not happen here so I suspect something in your setup probably of zsh.
Have you tried moving all your ~/.zsh* files and start with a blank environment?
Using Terminal.app on OS X 10.5, often you see the commands get garbled when you do a reverse-search with Bash. Is there some kind of termcap or perhaps a bash shopt command that can fix this? It is very annoying.
Steps to reproduce: Open Terminal.app, reverse-search to a longish command. Hit <ctrl>-E once you've found the command. The cursor goes to the end of the line, but the display doesn't update.
I'm guessing this is some kind of problem with the readline library on OS X. It's more of a problem with updating the cursor position after a search than anything else. Basically, ctrl-a and ctrl-e tend to break the search output.
os x terminal failure image http://involution.com/images/osxterminal.png
In the above, the first part of the command should be displayed, and the cursor should be at the end of the line, but it isn't. You literally can't see what you're editing when this happens.
I was able to set my TERM to xterm instead of xterm-color and it solves the problem. (export TERM=xterm).
You may want to look at this post.
bash-prompt-in-os-x-terminal-broken
I had the same problem and it had to do with the PS1 variable. Let me know if this helps.
If the prompt has colors, then this is an acknowledged bug.
See bug report msg#00019.
I've encountered this bug, and while I don't know how to solve it, you can work around it by pressing <down><up>
Not sure whether this is the problem here, but a very common cause of a messed up screen in bash (with any terminal emulator, not just Terminal.app) is the window being resized.
Bash will read the window size when it starts up, and then assume it hasn't changed. When the window is resized a signal will be sent to whatever app is currently reading from the console. If this isn't bash (because you're running a text editor at the time, perhaps), then bash won't know about it.
Solution in this case is to resize the window again so that bash gets the signal and notices the new size.
I can't reproduce this, hitting either Ctrl+E, Ctrl+A or the arrow keys updates the command line correctly. Are you running 10.5.4? Is it perhaps a bug in earlier versions?
In worst case, you could launch the X server (somewhere under utilities) and launch a real xterm.