I am sorry because this is not really a programmer question (well it becomes one when my bash script needs to change the prompt color), but this inconvenience has been bugging me ever since I started testing my code on Cygwin. When I type a very long command line with a lot of arguments, it breaks to the next line after 61 characters, not at the end of the line (80 in my case), as you would expect it to. When you use backspace, home, end, or left/right arrow keys, the cursor doesn't move as it should. Also, if one of your previous commands in your command history is long (longer that 61 characters), pressing up arrow key after reaching that command will produce a scrambled line. I first though this was a bug in Cygwin and tried to ignore it. After some (very long) research, I found out that the problem was in my profile file, and further research showed that the problem is caused by my prompt coloring.
Apparently, this is the cause of all the trouble:
PS1="\e[0;32m\w> \e[1;32m"
But this works quite fine (except it's the wrong color):
PS1="\w> "
Any ideas what might be the problem? Am I doing something wrong here?
I figured this out a while ago so I can't exactly explain it, but it needs to be like this:
PS1='\[\e[0;32m\]\w> \[\e[1;32m\]'
Basically you need to surround the escape sequences with \[ and \].
Related
I was working on my own bash prompt when hit strange behaviour (both iTerm and Terminal.app on macos). I managed to boil it down to the minimum working example:
~/.bash_profile:
WHITE="\[\033[1;37m\]"
COLOR_NONE="\[\033[0m\]"
# This always wraps correctly
PS1="\u:\w"
# This (added coloring) wraps incorrectly when using small window.
# PS1="${WHITE}\u:\w${COLOR_NONE}"
Now create a long directory name say
mkdir ~/very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name
and cd to it. Problem is: with the first version of the PS1 it wraps perfectly, while adding just one color breaks wrapping for small windows. Can anybody clarify of give a workaround? Adding \n to the end is an option, but looks ugly for short prompts.
Thanks!
Sources I have already seen:
BashFAQ/053 about colors
SO question about \[ and \]
Issue with \x01 and \x02
UPD:
bash version version 3.2.57(1)-release (x86_64-apple-darwin17)
Bash has always had trouble handling long prompts with invisible characters, so the usual practice is to avoid them. For example, you could automatically trim the length of the prompt by omitting the beginning of the path if it is too long, or you could automatically output a trailing newline if the path is very long. (In such cases, you might want to use $COLUMNS, which will normally tell you the width of the window.)
In patch 19 to bash v4.4 (which I realise is not really relevant to your environment since you seem to still be using the antique version of bash provided by a default OS X install), a long-standing bug was corrected, which had the effect of triggering a segfault in certain very rare cases of multiline prompts with both invisible and multibyte characters. The behaviour definitely changed between v4.4.18 and v4.4.19, but even with that patch very long prompts cause problems when the prompt extends to a third line.
There is a comment in lib/readline/display.c which indicates that the readline library assumes that prompts will not exceed two lines. I suggest that you use that as a limit.
I've been having trouble with a Capistrano script, or in fact, a bash command that was causing my script to fail. I kept on getting errors from the script saying:
No such file or directory
So here's the script bit.
run "sudo ln -s #{shared_path}/readme.txt #{shared_path}/readme-symlink.txt"
Upon closer inspection it turns out that there are two spaces between the readme.txt and readme-symlink.txt bits. By accident I found that one is a space, and the other is just a weird character that looks like a space, but it's not. Here's what it looks like in Sublime Text, configured to display whitespace:
Notice how, in the above image, there is only one dot after readme.txt, and then another "space"
So here's my question, what on earth is this charachter, I'm just so confused how someone managed to get that in there by typing on a normal keyboard?
So I pasted the string at http://www.asciivalue.com/index.php, the second space has an ASCII value of 160. According to http://www.ascii-code.com/ this is a space, but it's a non-breaking space, which I believe, the command line isn't too happy about.
Removing the nbsp fixes my script, and I can go on with my life again.
I'm just stumped about how the person that created the file got a nbsp in there in the first place.
Open up irb and
type gets. It should work fine.
Then try system("choice /c YN") It should work as expected.
Now try gets again, it behaves oddly.
Can someone tell me why this is?
EDIT: For some clarification on the "odd" behavior, it allows me to type for gets, but doesn't show me the characters and I have to press the enter key twice.
Terminal input-output handling is dark and mysterious art. Anyone trying to make colorized output of bash work in windows PowerShell via ssh knows that. (And various shortcutting habits like Ctrl+Backspace only make things worse.)
One of the possible reasons for your problem is special characters handling. Every terminal out there can type characters in number of different modes, and it parses its own output in search for certain character sequences in order to toggle states.
F.e. here one can find ANSI escape code sequences, one of possible supported standards among different kind of terminals.
See there Esc[5;45m? That will make all the following output to blink on magenta background. And there is significantly more stuff like that out there.
So, the answer to your question taken literally is — your choice command messes something with output modes using special escape sequences, and ruby's gets breaks in that quirk special mode of terminal operation.
But more useful will be the link to HighLine gem documentation. Why one might want to implement platform-specific and obtrusive behavior when it is possible to implement the same with about 12 LOC? All the respect for the Gist goes to botimer, I've only stumbled into his code using search.
I'm trying out the coffee script repl inside Emacs (under ArchLinux) and I'm seeing these escape characters surrounding the prompt:
[1Gcoffee> [0K[9G
These shouldn't be colors as I already enabled the ansi-color-for-comint-mode. So does anyone recognize these?
P.S.: Funny thing is I don't have this issue under my Emacs+Cygwin setup!
I don't know where they're coming from (something to do with your shell prompt, obviously, but it's hard to say more than that).
I read them as:
ESC[1G - Move to column 1 (Cursor Character Absolute)
ESC[0K - Erase to right
ESC[9G - Move to column 9
It looks like an attempt by the shell to ensure that the prompt is at the far left of an empty line. Not sure what shell you have, but zsh does something similar when the PROMPT_SP option is enabled. I don't think it uses the above sequences, though.
Many, many, control sequences can be found here. Note that the sequence "ESC[" is interpreted as a "Control Sequence Introducer" (CSI) and is shown as that on that page.
I had the same problem and was able to solve it by adding
export NODE_NO_READLINE=1
to my .bashrc file.
So, the characters appear to have come from the CoffeeScript REPL's use of Readline. Perhaps the reason you didn't have the issue in Cygwin was because Readline wasn't available there.
For some reason, I cannot jump forward with <C-I>; gives me the error beep. <C-O> works just fine.
I don't see any remapping going on either. Any ideas what might be the problem?
I'm using vim 7.3 on win7
EDIT: I just found out <C-I> does the same as %! I still can't figure out how to fix it though.
Why does having <TAB> mapped affect <C-I>? The short answer is, "historical reasons", dating from even before the original 'vi'.
The ASCII code for <TAB> is 9, same as <CTRL-I>. Since terminals receive their input encoded in ASCII, they can't tell whether that "TAB" signal came from the actual <TAB> key, or from the user holding CTRL and pressing I. Since Vim was originally written to run on terminals, it can't tell the difference either.
A couple of other pairs of indistinguishable keys are <C-M> with <Return>, and <C-[> with <Esc>.
It's possible there's some arcane way to tell the difference between the two (more likely if you're using GVim), but if there is, I don't know it. As a workaround, you could use nnoremap <SomeOtherKey> <C-I> to give <C-I>'s original function to some other key.
I found a fix for the problem, but I don't know why it works..
I had <TAB> mapped to %. By removing this, <C-I> works as normal.
Any idea why this works...?