print color escapes

print color escapes

[Ray Andrews]

All,

     $ print -r "\e[36msome cyanide salts are cyan\e[0m"
\e[36msome cyanide salts are cyan\e[0m

... does as expected, but how does one achieve the same 'literalness' if 
color escapes are in variables? I was forcing the 'colors' array to 
print bold colors and in the process the only way I could figure out to 
print the actual values of the 'fg[color]' colors was like this:

     $ print -r "before $($fg[cyan]) after"
     command not found: ^[[36m

... which is a bit clumsy, but it does at least show what's in there.  I 
tried various things, but can't find a legit way of printing the values 
of the color escapes.  How should it be done? Single quotes obviously 
won't work, double quotes seem needed to expand the variable, but I 
haven't found a way to stop it from being de-literalized.  But there 
will be a way.  Probably some magic nesting of braces. I'd expect 'print 
-r' to 'stay literal' with the expanded variable but no luck.

Re: print color escapes

[Bart Schaefer]

On Dec 31,  9:47pm, Ray Andrews wrote:
}
} tried various things, but can't find a legit way of printing the values 
} of the color escapes.  How should it be done?

You probably want either ${(V)fg[cyan]} or ${(q)fg[cyan]}.

torch% print -r ${(V)fg[cyan]}
^[[36m
torch% print -r ${(q)fg[cyan]}
$'\033'\[36m

} I'd expect 'print 
} -r' to 'stay literal' with the expanded variable but no luck.

It is staying literal with the expanded variable.  The variable has a
literal escape (ascii 033) in the value, not the string backslash e,
so print -r emits that literal escape etc.  It's the terminal that
then turns that into a color, not the print command.

Re: print color escapes

[Ray Andrews]

On 12/31/2014 10:35 PM, Bart Schaefer wrote:
> torch% print -r ${(V)fg[cyan]}
> ^[[36m
> torch% print -r ${(q)fg[cyan]}
> $'\033'\[36m
Thanks, either is usable.

} I'd expect 'print } -r' to 'stay literal' with the expanded variable 
but no luck.

 > It is staying literal with the expanded variable. The variable has a 
literal escape (ascii 033) in the value, not the string backslash e, so 
print -r emits that literal escape etc. It's the terminal that then 
turns that into a color, not the print command.

Ok, we hafta stop the terminal from doing it's thing when we want to 
'see' the escape code without the terminal 'doing' the escape code. But 
why/where is the change made?  I tried this script:

    cyan='\e[36;1m'
    norm='\e[0m'
    print    "1: $fg[cyan] howdy $norm"
    print    "2: $cyan howdy $norm"
    print -r "7: the value of fg[cyan] is: ${(V)fg[cyan]}"
    print -r "8: the value of cyan       is: ${(V)cyan}"


    1:  howdy << nicely cyan
    2:  howdy << nicely cyan
    7: the value of fg[cyan] is: ^[[36;1m      << modified to 'bold' by me.
    8: the value of cyan       is: \e[36;1m

... either the " \e[ " or the " ^[[ " form produces the color change, so 
why does the 'color' function 'bother' to change from one form to the 
other, and how/where?  I see the escape created like this:

     local lc=$'\e[' rc=m

... so how does it end up like: " ^[[ " ?

BTW I know you can't type " ^[[ " and have it work, the " ^[ " 
represents the escape code but can't create it, so I know it's a 'safe' 
way of showing the code, but since both my '$cyan' and 'fg[cyan]' seem 
to work the same way,  I'm confused as to what the point of the 
difference is.

Re: print color escapes

[Bart Schaefer]

On Jan 1, 11:24am, Ray Andrews wrote:
}
} Ok, we hafta stop the terminal from doing it's thing when we want to 
} 'see' the escape code without the terminal 'doing' the escape code. But 
} why/where is the change made?

The pair "\e" is interpreted by the "print" command and changed into an
ascii 033 character, UNLESS you use the -r or -R options.  So in your
script:

}     cyan='\e[36;1m'
}     norm='\e[0m'
}     print    "1: $fg[cyan] howdy $norm"
}     print    "2: $cyan howdy $norm"

above, "print" has changed \e to ESC, but:

}     print -r "7: the value of fg[cyan] is: ${(V)fg[cyan]}"
}     print -r "8: the value of cyan       is: ${(V)cyan}"

there, print has *not* done so.

The value of $fg[cyan] already has a literal ESC in it, so "print" does
nothing with that either way.  In these lines:

}     7: the value of fg[cyan] is: ^[[36;1m      << modified to 'bold' by me.
}     8: the value of cyan       is: \e[36;1m

There (V) flag has changed the literal ESC into ^[ for display, but there
is no literal ESC in $cyan so the (V) flag did nothing.

} ... either the " \e[ " or the " ^[[ " form produces the color change, so 

No, NEITHER of those forms produce the color change.  What produces the
color change is the literal ESC, which occurs either because it is already
there ($fg[cyan]) or because the "print" command translated \e ($cyan).

} why does the 'color' function 'bother' to change from one form to the 
} other, and how/where?

The color function does not change the form.  The (V) flag does, to make
it "visible".

} I see the escape created like this:
} 
}      local lc=$'\e[' rc=m

In that expression, the $'' form of quoting converts \e to ESC, which is
why the $'' form of quoting exists in the first place (and is different
from ordinary single quoting).  $'' is to avoid having to do something
more expensive (fork + read output) such as lc="$(echo '\e[')".

The (V) flag converts ESC to ^[ because that's what most people are used
to seeing ("visible").  The (q) flag converts to $'\e' because that's
what people are used to writing (and because "eval ${(q)...}" needs it
in that format).  The print and echo commands convert \e to ESC because
of historical practice.  The bindkey command converts both ^[ and \e to
ESC for maximum flexibility in writing key bindings.  All of this is
entirely independent of what the terminal does when it sees an ESC.

-- 
Barton E. Schaefer

Re: print color escapes

[Ray Andrews]

On 01/01/2015 01:29 PM, Bart Schaefer wrote:


Excellent, the whole question boils down to this:

> }      local lc=$'\e['
>
>
> In that expression, the $'' form of quoting converts \e to ESC, which is
> why the $'' form of quoting exists in the first place (and is different
> from ordinary single quoting).  $'' is to avoid having to do something
> more expensive (fork + read output) such as lc="$(echo '\e[')".

That is a POSIX quote?  Good to see one in combat, I've only ever had 
them drawn to my attention once before.  Book lernin' no substitute for 
seeing something in action.
> The (V) flag converts ESC to ^[ because that's what most people are used
> to seeing ("visible").  The (q) flag converts to $'\e' because that's
> what people are used to writing (and because "eval ${(q)...}" needs it
> in that format).

Beautiful, these are conventions and practicalities not 'realities'.
> The print and echo commands convert \e to ESC because
> of historical practice.
But terminal will always grab ESC 'hard' will it not?  That is to say 
that no matter how you dress it up, the terminal always sees it 
verbatim.  And I'd expect that that convention is now written in stone.
> The bindkey command converts both ^[ and \e to
> ESC for maximum flexibility in writing key bindings.  All of this is
> entirely independent of what the terminal does when it sees an ESC.
>
Crystal clear.  Too bad there wasn't some way of upvoting an explanation 
like that were it to show up on Google eventually, cuz that's as good as 
it could be. Questions that were not even asked (but needed to be) were 
answered.

BTW too bad in some fonts '' looks almost exactly like ".

Re: print color escapes

[Bart Schaefer]

On Jan 1,  3:02pm, Ray Andrews wrote:
}
} But terminal will always grab ESC 'hard' will it not?  That is to say 
} that no matter how you dress it up, the terminal always sees it 
} verbatim.

Yes, but ESC only means something to the terminal when it is followed
"soon enough" (temporally) by the series of characters that forms a
terminal escape.  (Sometimes that's only one character.)

} And I'd expect that that convention is now written in stone.

It's an ANSI (American National Standards Institute) standard dating
back a few decades, so yeah, not likely to change.

} BTW too bad in some fonts '' looks almost exactly like ".

Sometimes I just get tired of typing ellipses.

Re: print color escapes

[Ray Andrews]

On 01/01/2015 03:26 PM, Bart Schaefer wrote:
> } BTW too bad in some fonts '' looks almost exactly like ".
>
> Sometimes I just get tired of typing ellipses.
I've often wished for a programmer's font, who's point is to make all 
characters very distinct, for situations  where clarity is everything, 
and pleasing appearance is nothing.  '' " | ! I l 1 0 O ...

Re: print color escapes

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

On Thu, Jan 1, 2015 at 6:30 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> I've often wished for a programmer's font, who's point is to make all
> characters very distinct, for situations  where clarity is everything, and
> pleasing appearance is nothing.  '' " | ! I l 1 0 O ...
>

"Andale Mono" and "Inconsolata" are two reasonably good options that I've
been using for a long time. As I get older I too get annoyed when I can't
easily distinguish between a "O" and "0" for example and the aforementioned
fonts are good in that respect.  However, I can't vouch for their ability
to handle non-USA character sets.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: print color escapes

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

On 01/01/2015 06:45 PM, Kurtis Rader wrote:
> On Thu, Jan 1, 2015 at 6:30 PM, Ray Andrews <rayandrews@eastlink.ca 
> <mailto:rayandrews@eastlink.ca>> wrote:
>
>     I've often wished for a programmer's font, who's point is to make
>     all characters very distinct, for situations  where clarity is
>     everything, and pleasing appearance is nothing.  '' " | ! I l 1 0
>     O ...
>
>
> "Andale Mono" and "Inconsolata" are two reasonably good options that 
> I've been using for a long time. As I get older I too get annoyed when 
> I can't easily distinguish between a "O" and "0" for example and the 
> aforementioned fonts are good in that respect.  However, I can't vouch 
> for their ability to handle non-USA character sets.

Most cool.  I've never tried to add a font to Linux, can you point me in 
the right direction?  Some good doc?
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank

Re: print color escapes

[Bart Schaefer]

On Jan 1,  7:50pm, Ray Andrews wrote:
} Subject: Re: print color escapes
}
} 
} On 01/01/2015 06:45 PM, Kurtis Rader wrote:
} > On Thu, Jan 1, 2015 at 6:30 PM, Ray Andrews <rayandrews@eastlink.ca 
} > <mailto:rayandrews@eastlink.ca>> wrote:
} >
} >     I've often wished for a programmer's font, who's point is to make
} >     all characters very distinct
} >
} > "Andale Mono" and "Inconsolata" are two reasonably good options

Or anything with "console" or "terminal" in its name may be a good bet
if you don't have those available.

Some of your non-technical email may look strange if you force your mail
reader to display in those fonts, though.

} I've never tried to add a font to Linux, can you point me in 
} the right direction?  Some good doc?

It depends on your Linux distribution, probably.  Usually you install
fonts as software packages like you'd install any other program.  In
your package manager, try searching for "truetype" or "ttfont" or just
"font".

(And once again we've wandered off-topic, but it's hard to use a shell
without a good fixed-width font.)

Re: print color escapes

[Ray Andrews]

On 01/01/2015 08:18 PM, Bart Schaefer wrote:
> } >
> } > "Andale Mono" and "Inconsolata" are two reasonably good options
Tx.
> It depends on your Linux distribution, probably.  Usually you install
> fonts as software packages like you'd install any other program.  In
> your package manager, try searching for "truetype" or "ttfont" or just
> "font".
>
Yup, just like any other package.  Why did I suppose different.

Re: print color escapes

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]

On Thu, Jan 1, 2015 at 3:02 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

But terminal will always grab ESC 'hard' will it not?  That is to say that
no matter how you dress it up, the terminal always sees it verbatim.  And
I'd expect that that convention is now written in stone.


The terminal always sees every character verbatim. How it treats the
character depends on many things. In the past (circa the 1980s) you could
purchase "smart" terminals from different companies each of which
implemented their own "language". Language in this context means the
 specific mapping of character sequences to actions such as clearing the
screen or changing the foreground color. The reason the terminfo and
termcap databases and associated programming APIs exist (try typing "man
terminfo" or "man tercap" at your shell prompt) was to make it possible for
programs to perform actions like moving the cursor to a specific location
on the screen without explicitly knowing which control language the
terminal implemented.

One of those was the DEC VT100. The "language" it recognized eventually
became the winner. Winner in the sense that by the 1990s nearly all
terminals implemented that language. That de-facto standard was eventually
turned into standard ANSI X3.64
<http://en.wikipedia.org/wiki/ANSI_escape_code> which is now pretty much
the only terminal control language you'll find in use.

P.S., Yes, I've glossed over many important details above. Such as the fact
the DEC VT52 was actually the first terminal to implement what would
eventually become the ANSI X3.64 standard. But it was the VT100 that made
that transition all but inevitable. Today things are even more complicated
by Unicode and encodings such as UTF-8 which a terminal should understand
in order to translate multi-byte characters into the appropriate human
language glyph.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: print color escapes

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On 01/01/2015 05:21 PM, Kurtis Rader wrote:
>
> One of those was the DEC VT100. The "language" it recognized 
> eventually became the winner. Winner in the sense that by the 1990s 
> nearly all terminals implemented that language. That de-facto standard 
> was eventually turned into standard ANSI X3.64 
> <http://en.wikipedia.org/wiki/ANSI_escape_code> which is now pretty 
> much the only terminal control language you'll find in use.
>
I'm just realizing something that might not be true:  In the old days, 
it would have been the hardware terminal itself that interpreted these 
codes, but now, it's my 'terminal emulator', not the screen itself, 
which is why it's called an 'emulator'. Correct?  And I can't believe 
I'm saying this, but too bad that these control characters are part of 
the data stream, there should have been a 'vi' insert vs. control mode.  
One special char, and you're in control mode until you toggle out of it 
again.

Re: print color escapes

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

On Thu, Jan 1, 2015 at 6:39 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I'm just realizing something that might not be true:  In the old days, it
> would have been the hardware terminal itself that interpreted these codes,
> but now, it's my 'terminal emulator', not the screen itself, which is why
> it's called an 'emulator'.  Correct?  And I can't believe I'm saying this,
> but too bad that these control characters are part of the data stream,
> there should have been a 'vi' insert vs. control mode.  One special char,
> and you're in control mode until you toggle out of it again.
>

The "hardware terminal" you refer to was itself a computer that executed
code. The only difference between it and the "terminal emulator" you're
likely using today is that the former was embedded in a piece of hardware
with a very narrow function whereas the modern terminal emulator (e.g.,
iTerm2 that I use on Mac OS X) runs on a device with a very broad function.
But they both execute programs that recognize specific input sequences and
act accordingly (e.g., clearing the "screen").

The whole point of the ANSI X3.64 standard (as partially implemented by the
DEC VT100) was to implement  a vi style of insert versus control mode. The
CSI sequence (ESC [) switched the terminal from "insert" to "control" mode.
And once the control command (e.g., clear screen) was recognized and acted
upon the input mode reverted to "insert".

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: print color escapes

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On 01/01/2015 06:58 PM, Kurtis Rader wrote:
> On Thu, Jan 1, 2015 at 6:39 PM, Ray Andrews <rayandrews@eastlink.ca 
> <mailto:rayandrews@eastlink.ca>> wrote:
>
>
>
> The "hardware terminal" you refer to was itself a computer that 
> executed code. The only difference between it and the "terminal 
> emulator" you're likely using today is that the former was embedded in 
> a piece of hardware with a very narrow function

Exactly what I was saying.

> The whole point of the ANSI X3.64 standard (as partially implemented 
> by the DEC VT100) was to implement  a vi style of insert versus 
> control mode. The CSI sequence (ESC [) switched the terminal from 
> "insert" to "control" mode. And once the control command (e.g., clear 
> screen) was recognized and acted upon the input mode reverted to "insert".
>
Yeah, ESC is rather obviously a 'control' mode.  What I was thinking is 
that it would end only at the same ESC code again--a toggle--which 
would/might make the control codes themselves a bit shorter and sweeter. 
Or not.  Maybe it really is easier to have the codes self terminate. 
Anyway, that's never going to change of course, but interesting to think 
about.