Given the shell script myPrompt.sh:


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"

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 different results than manual invocation even though they're executing the exact same bash script file 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?

1 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:

  • 2
    Bash seems to internally change \[ and \] to 0x01 and 0x02. You can see that with something like foo='\[\033[00;36m\]'; printf "%s\n" "${foo@P}" |od -c; you should get 001 033 [ 0 0 ; 3 6 m 002 \n. So even though prompt escapes like \u, \h and \[/\] are sadly only usable before variables are expanded, using 0x01 and 0x02 could indeed work to circumvent that.
    – ilkkachu
    Oct 12, 2021 at 17:33
  • 1
    ooh that's interesting! thanks for illuminating that detail
    – underrun
    Oct 12, 2021 at 19:03
  • So certain special characters like \001 and \002 or their counterparts \[ and \] are interpreted different by the Prompt and Bash. And you can use @P at the end of a string to force Prompt style interpretation + expansion. Fascinating and great answer, thank you. I'd love to see a link to documentation explaining the usage of @P in more detail. Oct 22, 2021 at 1:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .