6

I have trouble understanding what \[\e]0;$PWD\007\] and \[\e(0\]b\[\e(B\] mean.
I am setting up my prompt on MobaXterm on Windows and those two sequences were in the default one. They were at the very beginning and very end respectively.

Here is a screenshot of the resulting prompt: enter image description here

I think the second one is used to show the small arrow replacing the traditional $ but I have no idea how it achieves this result. It almost looks like garbage. I suppose it's some kind of unicode trick?

Regarding the first one, I have absolutely no idea what its purpose is. I'm even more troubled by the $PWD part.

About the linked question:

Well, as I mentionned, I know that the second sequence displays the arrow but why does it use two escape sequences separated by a plain b? That's very strange.
And, regarding the first one, it doesn't show the PWD. In my screenshot, this sequence is displayed at the very beginning, even before the date is printed. The purple path uses a classic \w. I don't understand why it uses $PWD inside an escape sequence, that's why I asked the question.

Telokis
  • 162
  • 6

1 Answers1

4

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

enter image description here

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.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Thomas Dickey
  • 76,765
  • Thank you for this in-depth answer. I really didn't expect something that complex to happen with this sequences. – Telokis Jan 03 '19 at 09:35