Bash prompt - octal representation of multibyte unicode characters works for prompt but not when run manually (same script)?

Question

Given the shell script myPrompt.sh:

#!/bin/bash

printf "Llama \001\360\002\001\237\002\001\255\002\254 Llama $> "

... and the bash prompt configured to run above script:

alias myPrompt="/home/you/myPrompt.sh"
PS1="\$(myPrompt)"

In the above described scenario, the function runs and produces output with the [🭬] displayed correctly.

However, if I manually invoke the same exact script via: ./myPrompt.sh the output is different and the unicode character displayed is corrupt relative to the octal representation being printed.

This picture highlights the issue well. The Bash Prompt is clearly producing correct results while the manual invocation messes it up, even though they're executing the exact same script. Why is it that my script executes and displays correctly when run automatically as my bash prompt but not if I manually run the bash script?

Story And Research of Said Problem

Originally, I was primping out my bash prompt with a custom bash script and ran into a great headache trying to incorporate an obscure unicode character from the extended symbol character space. Specifically with this big chungus triangle character [🭬]. It displayed fine when run as my bash prompt. However, any subsequent line wrapping broke, causing all sorts of hell when typing out long commands.

Eventually, I determined this was because the big chungus triangle unicode character was throwing off the terminal by reporting it was 4 characters even though it visually only takes up 1 char space.

Simply explained, these larger unicode characters are actually smaller unicode characters combined together in a specific order and the terminal visually displays them correctly but internally gets confused and increments the column it thinks the cursor is at by more than the one visually displayed character.

So 10 hours later I finally figured out I could break my unicode character down into four octals and then wrap the first three of the 4 octals in \001 & \002. By wrapping them like this I'm essentially telling the terminal, hey feed this character to the output/display but don't increment the column position. That worked wonders, the weird unicode character was displayed in my prompt and the terminal wouldn't mess up if line wrapping occurred in my command.

Just when I thought I was done, something caught me. The script runs fine as my bash prompt, however when invoked manually, the script outputs corrupted unicode garbage. What gives, is PS1 doing something with the output of my shell script other than just executing my shell script?

Answer 1

Some sequences like \[ and \] are used by shell when processing a prompt to do things like note zero width sections of the prompt, but these characters are not interpreted that way when being printed directly. I'm surprised that the \001 and \002 work the way you note - but that may have more to do with whatever character encoding you are using?

In any case, to print something and see what it would look like on your prompt without setting your prompt, in bash you can use the P (for prompt) operator in variable expansion:

SOME_PROMPT_STRING="\u@\h:\W\$"
echo "${SOME_PROMPT_STRING@P}"