Re: prompt with \w incl. long UTF string messes up command line

[Linda Walsh]

Your prompt might be too long.

Your 'dir' string is awfully long...
echo "$dir"|wc -c
270
---

I tried a shorter version on linux:
sdir='△△△△△△△△△△△△△_ >'
pre='Ishtar:/tmp/' ## prefix of my dir
Ishtar:/tmp/△△△△△△△△△△△△△> 
012345678901234567890123456
-bash: 012345678901234567890123456: command not found
Ishtar:/tmp/△△△△△△△△△△△△△> echo ${#pre}+${#sdir}=$[${#pre}+${#sdir}]
12+13=25
My cursor started in col 27 with 26 chars preceding it.
As you can see above adding the length in chars
of the prefix and the UTF chars together, I get 25, + the '>'
at the end=26.  and together :
Ishtar:/tmp/△△△△△△△△△△△△△> echo "$pre$sdir>"|wc -c
53
are only 53 bytes long.






Ryo Furue wrote:
> When PS1 includes \w and when \w contains long path including UTF
> characters, the cursor position or the command line is messed up.
>
> Repeat-By:
> 1. Source the attached script:
>   $ . bash-prompt-bug.sh
>
> 2.1. You'll find the prompt is messed up: shorter than the
>    real path name, garbage character at the top.
> 2.2. If you use the tput commands, which are commented out
>    in bash-prompt-bug.sh, the prompt is fine, but the cursor
>    position is messed up.
>
> 3. After 2.2, try to complete filenames by pressing TAB,
>   and sometimes you'll find the cursor position is
>   even more badly messed up.
----
        Bash doesn't honor tabs as set on your terminal
at all.  It always expands them to '8' spaces and it's concept
of where it is vs. using actual tab chars which would have
output looking like what you typed.

> I tested this both on the latest versions of iTerm and Terminal on Mac
> OS 10.11.1 .
----
        I tested this on bash 4.3.39.  Maybe the MAC doesn't
handle the expansions right?