The reason why each case consists of something "bracketing" some data is that it is telling the terminal to start doing something, then sending the data, and then finish doing something.
The first sequence is the xterm control which bash can use to put the value of $PWD
in the window title (and icon name). You wouldn't see anything in the prompt for that. The shell value $PWD
is data, the left-side begins an escape sequence and the right-side finishes the sequence.
The other one switches to the VT100 line-drawing character set (see Designate G0 Character Set: 0
goes to line-drawing, B
goes back to Latin-1) to print (something) for b. But a real VT100 doesn't show an arrow key for that (it would show an "HT", for horizontal tab):

However, some "VT100 emulators" make up their own choices (though usually they leave the original VT100 choices alone). Interestingly, though MobaXterm is based on PuTTY, PuTTY documents the earlier VT52 choices in a comment (though it does not implement the one for b):
/*
* From the VT100 Manual
* NOTE: The special graphics characters in the VT100
* are different from those in the VT52
*
* From VT102 manual:
* 137 _ Blank - Same
* 140 ` Reserved - Humm.
* 141 a Solid rectangle - Similar
* 142 b 1/ - Top half of fraction for the
* 143 c 3/ - subscript numbers below.
* 144 d 5/
* 145 e 7/
* 146 f Degrees - Same
* 147 g Plus or minus - Same
* 150 h Right arrow
* 151 i Ellipsis (dots)
* 152 j Divide by
* 153 k Down arrow
* 154 l Bar at scan 0
A real VT100 would also emulate a VT52, so PuTTY has some code related to a VT52. But the escape sequence shown won't get that far—it's only VT100. As for why the VT52 provided a right-arrow and a down-arrow, but not an up-arrow or left-arrow, that isn't clear, some ~40 years later. But the developer for MobaXterm probably decided to improve things using a code which did not appear that useful.
The source for MobaXterm's terminal emulator is on their website as "MoTTY". The table used for line-drawing characters looks like this:
/* Character conversion arrays; they are usually taken from windows,
* the xterm one has the four scanlines that have no unicode 2.0
* equivalents mapped to their unicode 3.0 locations.
*/
static const WCHAR unitab_xterm_std[32] = {
//MOBAMODIF
// 0x2666, 0x2592, 0x2409, 0x240c, 0x240d, 0x240a, 0x00b0, 0x00b1,
0x2022, 0x2592, 0x27a4, 0x240c, 0x2714, 0x2718, 0x00b0, 0x00b1,
//END_MOBAMODIF
0x2424, 0x240b, 0x2518, 0x2510, 0x250c, 0x2514, 0x253c, 0x23ba,
0x23bb, 0x2500, 0x23bc, 0x23bd, 0x251c, 0x2524, 0x2534, 0x252c,
0x2502, 0x2264, 0x2265, 0x03c0, 0x2260, 0x00a3, 0x00b7, 0x0020
};
That first line is what they changed (the comment is from PuTTY, in turn adapting from xterm). Rendering that first line as UTF-8 on xterm shows what the characters are (hint: the first entry is octal 140, or `):
8226 ->0x2022 ->{•} (4 bytes, punct)
9618 ->0x2592 ->{▒} (4 bytes, printing)
10148 ->0x27a4 ->{➤} (5 bytes, printing)
9228 ->0x240c ->{␌} (4 bytes, printing)
10004 ->0x2714 ->{✔} (5 bytes, printing)
10008 ->0x2718 ->{✘} (5 bytes, printing)
176 ->0xb0 ->{°} (3 bytes, printing)
177 ->0xb1 ->{±} (3 bytes, printing)
The suggested duplicate is unrelated to either part of the question, particularly the second part because the prompt string is not using UTF-8, but rather a different encoding.
b
? That's very strange. – Telokis Jan 02 '19 at 23:49\w
. I don't understand why it uses$PWD
inside an escape sequence, that's why I asked the question. – Telokis Jan 02 '19 at 23:50