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.
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 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 \].
When using Mac OS X including iTerm, I can simply press
Shift+$ and the line in bash that I am currently tiping will get a # added to the beginning and the line returns. I like this very much as it prevents from actually executing that command while still editing it and I don't have to jump to the beginning of the line to insert that # character there.
However, when I log onto our cluster, this functionality is lost. I tried to search for this feature but only found posts about using sed etc. so suggestions which are not for the interactive kind of using bash that I am referring to.
Could somebody please point me to a resource where this functionality is explained (bash-guide?) so I could look up how to make it work when logging in to other machines? Or is this something Mac/iTerm-specific? But then, I would expect it to work also on our cluster, as long as I use my machine of course.
This might work for you
See insert-comment (M-#)
I've got a Cocoa app that parses text from a standard text file. When using terminal programs like nano and pico to edit the file, I'll sometimes notice that a ^M character shows up. I can't reproduce this on later versions of Mac OS X, but it seems to abound in version 10.5.
Oddly, when I take a file that has the ^M character in it from a 10.5 system, it magically goes away in 10.6+; I'm assuming this is because Mac OS started to convert the linux-style linefeeds into Mac-style (??). Consequently, it has made it somewhat complex to fix the problem at debug-time since I have XCode only installed on 10.7.
I need a way to find the ^M character and replace it with something more standard (like \n) while I'm parsing the file. What type of character do I need to look for? It doesn't seem to be a \n and likewise, no combination of \r\n seems to do the trick either. The ^M still hangs around.
This is easy to manage within XCode.
Simply select the file you want to change the line endings for and then open up the utilities panel and you can change the Line Endings.
Like so:
I'm not a MacOS user, in general, so I'm only guessing this will work. On typical Unix-like systems, you can use Ctrl-V to get the next control character you enter to appear as a visible character sequence. Thus, for instance, you might be able to get the ^M you want to appear by first entering Ctrl-V, then pressing your Return key. Note that the ^M that appears on your screen in this case is not the same (from the perspective of your software) as the ^M that appears when you first enter the ^ character then the M character. In this manner, you can do things like use regular expressions to replace that ^M control character representation with instances of \n instead.
You could also, as Jakrabbit suggests, use dos2unix to filter the file -- assuming it's available on your Mac.
"^M" is a representation of the ASCII line feed character. This is character code 13 in ASCII (and UTF-8), so when parsing the file, look for characters with a value of 13 and just ignore them.
^M is the standard carriage return character in DOS/Windows.
I would just use the dos2unix program to get rid of them all.
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.