No emoji in bash prompt when launch

[trstringer]

I'm seeing an interesting thing. My bash prompt I have configured an emoji in it, and when launching hyperterm it doesn't recognize it immediately, but it does for all subsequent prompts. See the screenshot below that shows the repro:

[kimumetal]

I want to work on this issue. I discovered that:

1. When there is no \n in .bash_profile, this bug does not appear. I can reproduce the same bug when there is \n in .bash_profile.

[3j14]

Can you show us your .bash_profile?

[trstringer]

@Jonas-Drotleff here it is:

export PS1="\u@\h 🌺  \w 
 $ "

[christanaka]

I have an issue where using ⚡️(high voltage) always shows ⚡︎ (high voltage sign) instead.

# .bash_profile
export PS1='⚡️ \W '

[3j14]

@chrishtanaka This is because you use a font that actually has a symbol for the ⚡️ unicode character. The system will always use the font's icons first and if they don't exist, it will take a fallback font, which is the emoji font on macOS

[christanaka]

@Jonas-Drotleff How would I determine which fonts have symbols for ⚡️ without trying out each one in hyper?

[3j14]

@chrishtanaka

This is what I found on the web:

• CharMapEx
• Character To Glyph Index Mapping Table

Basically you just have to try...

[simeydotme]

To add to this issue, I find the same thing with any unicode character, even if I try to encode it myself.

PS1="$ " # no problem
PS1="❭ " # problem
PS1=$'\xe2\x9d\xad\x0a ' # problem

The error I see in console is:

I stepped through the loop, and find that it's running conversion fine on a bunch of characters (although they seem unrelated?) but then it gets to an undefined and finally crashes. This method (lib.UTF8Decoder.prototype.decode) doesn't seem to run when entering a new line in to the terminal, but only upon opening a new tab.

[simeydotme]

Ah, think I've spotted the issue maybe; I have no idea how to test as the console crashes every time I try to re-compile the code, so I can't patch;

__WEBPACK_IMPORTED_MODULE_0_hterm_umdjs__["hterm"].Terminal.IO.prototype.writeUTF8

This method here, the loop is using <= on the length of the string ... (10 for me) but it's zero-indexed and incrementing, meaning the last iteration always has an undefined value because it's looking for length + 1 .

I suspect changing the <= to a < should resolve this issue :)

[zpnk]

Seeing the same issue here. Simple repro:

# ~/.bash_profile
export PS1='\n 💭 '

Results in:

With the same error as @simeydotme : Uncaught TypeError: Cannot read property 'length' of undefined

Like @vwvww mentioned, removing the newline \n "fixes" it. Removing the unicode character while keeping the \n also "fixes" it, but obviously neither are real solutions.

For those bothered by this bug a temporary remedy is to add a clear statement the end of your profile which will cause the buggy prompt to be cleared when a new tab/window is opened:

# ~/.bash_profile
export PS1='\n 💭 '
clear

Looks to me like the lib.UTF8Decoder.prototype.decode needs to be fixed to handle \n.

[simeydotme]

I think this is fixed by #1366 :) (at least it's fixed in the latest version; 1.1.0, for me)

[ppot]

Thanks @simeydotme