Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > printf in glorious colour

Reply
Thread Tools

printf in glorious colour

 
 
James Kuyper
Guest
Posts: n/a
 
      03-02-2013
On 03/02/2013 06:41 AM, Nobody wrote:
> On Fri, 01 Mar 2013 12:49:46 -0500, James Kuyper wrote:
>
>> On 03/01/2013 07:29 AM, Nobody wrote: ...
>>> On a related note, even \r (carriage return), \b (backspace) and \a
>>> (bell) aren't universally supported. ...

>>
>> If it's a conforming implementation of C, those characters must be
>> supported:

>
> That only requires that the implementation map those sequences to the
> appropriate codes in the platform's "native" encoding (e.g. 13, 8 and 7
> respectively for ASCII, 13, 22 and 47 for EBCDIC).


No, it doesn't even require that. A fully conforming implementation
could map those sequences to inappropriate codes.

> The behaviour of terminals is outside the scope of the C standard.


Perhaps - but 5.2.2 does in fact specify the intended behavior of
display devices.
--
James Kuyper
 
Reply With Quote
 
 
 
 
Ivan Shmakov
Guest
Posts: n/a
 
      03-02-2013
>>>>> Nobody <(E-Mail Removed)> writes:
>>>>> On Fri, 01 Mar 2013 02:04:24 -0800, Malcolm McLean wrote:


[Cross-posting to news:comp.unix.misc, just in case.]

>> How widely supported are the escape ... m colour codes for text?


> There are enough exceptions that hard-coding those sequences can't be
> explained as anything other than the programmer not knowing about
> termcap or terminfo.


Seconded. However, it should be noted that, say, both ls(1) of
GNU Coreutils and vlc(1) of the VideoLAN project have these
hardcoded. (And while it may be reasonable for the first, I
doubt that it is for the second.)

> Any Unix system will have either or both of those libraries.


As well as a variant of the Curses library.

> The Windows console doesn't support escape sequences.


Still, there're PDCurses.

[...]

--
FSF associate member #7257
 
Reply With Quote
 
 
 
 
Ivan Shmakov
Guest
Posts: n/a
 
      03-02-2013
>>>>> Malcolm McLean <(E-Mail Removed)> writes:
>>>>> On Friday, March 1, 2013 12:29:54 PM UTC, Nobody wrote:
>>>>> On Fri, 01 Mar 2013 02:04:24 -0800, Malcolm McLean wrote:


[Cross-posting to news:comp.terminals, and setting Followup-To:
there, for that'd be a more appropriate newsgroup.]

>>> How widely supported are the escape ... m colour codes for text?


>> There are enough exceptions that hard-coding those sequences can't
>> be explained as anything other than the programmer not knowing about
>> termcap or terminfo.


>> On a related note, even \r (carriage return), \b (backspace) and \a
>> (bell) aren't universally supported. And even where \r and \b are
>> supported, their behaviour differs between video and hardcopy
>> terminals.


> Then situation is that an embedded system running embedded Linux is
> spitting out ASCII text to a console which runs under Windows. I'm
> writing both the embedded side code to get the text, and the Windows
> side code to communicate with the device and read it. So the
> question is where to strip the escape sequences out.


FWIW, "pure" ASCII text isn't supposed to contain such escape
sequences.

However, I wonder if it's possible to use either MinTTY or PuTTY
for the task at hand? Both of them are capable of ECMA-48
escape sequences, including that for colors. (And PuTTY also
supports serial port communication, BTW.)

[...]

--
FSF associate member #7257
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      03-09-2013
On Mar 1, 2:13*pm, Malcolm McLean <(E-Mail Removed)>
wrote:
> On Friday, March 1, 2013 12:29:54 PM UTC, Nobody wrote:
> > On Fri, 01 Mar 2013 02:04:24 -0800, Malcolm McLean wrote:

>
> > > How widely supported are the escape ... m colour codes for text?

>
> > There are enough exceptions that hard-coding those sequences can't be
> > explained as anything other than the programmer not knowing about termcap
> > or terminfo.

>
> > On a related note, even \r (carriage return), \b (backspace) and \a (bell)
> > aren't universally supported. And even where \r and \b are supported,
> > their behaviour differs between video and hardcopy terminals.

>
> Then situation is that an embedded system running embedded Linux is spitting out ASCII text to a console which runs under Windows. I'm writing both the embedded side code to get the text, and the Windows side code to communicate with the device and read it. So the question is where to strip the escape sequences out. There's no option other than to hard-code them because I can't control the embedded side programs that are producing the output stream.


my instinct would be to leave the embedded side to do its own thing
and process the data into something escape free on the host (is it
always going to be windows?) side.

{red}hello! {blue,bold}world.

HTML I suppose if you must

Your console driver then translates it back into whatever the terminal
supports.

I tend to hate implementation detail from the edges of the system
leaking into the core application. I've seen highly compressed radio
protocol values stored in server side RdBs and no one being able to
see a problem (until the bit representation on the air interface
changed...)
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      03-09-2013
On Saturday, March 9, 2013 10:58:20 AM UTC, Nick Keighley wrote:
> On Mar 1, 2:13*pm, Malcolm McLean <(E-Mail Removed)>
>
> my instinct would be to leave the embedded side to do its own thing
> and process the data into something escape free on the host (is it
> always going to be windows?) side.
>
> I tend to hate implementation detail from the edges of the system
> leaking into the core application. I've seen highly compressed radio
> protocol values stored in server side RdBs and no one being able to
> see a problem (until the bit representation on the air interface
> changed...)
>

The embedded side runs embedded Linux. Initially my console just supported passing comand line arguments to the shell, to be executed via popen().
But that didn't allow for interactive commands, which interleave reads
from stdin with output to stdout.
It turns out that supporting these on Linux is a real hassle, and I ended
up using a pseudo terminal (the program pty). However when you run ls
under pty its behaviour changes, and suddenly it starts outputting the
colour codes.
For development we mostly use Linux machines, but some of the tools work
only under Windows.
 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      03-11-2013
On Fri, 1 Mar 2013 18:30:43 +0000 (UTC), glen herrmannsfeldt
<(E-Mail Removed)> wrote:

> James Kuyper <(E-Mail Removed)> wrote:
> > On 03/01/2013 07:29 AM, Nobody wrote:

>
> >> On a related note, even \r (carriage return), \b (backspace) and \a (bell)
> >> aren't universally supported. ...

>
> > If it's a conforming implementation of C, those characters must be
> > supported: <snip 5.2.1p3, 5.2.2p2>

>
> The corresponding ASCII characters are reasonably well defined.
>

Although the 'alternate' interpretation of LF as NL was often an issue
-- quite a few terminals needed a switch/jumper/etc. for it.

> There is an EBCDIC backspace, so that should also work.
>
> EBCDIC has CR, LF, and NL. I am not sure which one is used for '\n'
> for EBCDIC C systems. I don't know of EBCDIC systems with a bell.
> (There is a BEL control character, but I don't know what it does
> on any system.)
>
> The IBM 2741, the non-ASCII terminal most commonly used with IBM
> mainframes, isn't EBCDIC. (It has its own character set based on
> the position of the characters on the selectric type ball.)
> As I remember, and as wikipedial says, there is no character
> carriage return or bell character. There is BS, LF, and NL.
>

And HT, although the tab stops were manually set and often wrong.

But I think 327X/328Xs were are at least as common as 2741's. And in
practice all EBCDIC, although theoretically there were ASCII models to
match S/360's not-really-usable PSW.ASCII bit.

327X displays use specialized meanings of DC1-4 ESC and I think one or
two other controls. 328X printers could just use 327X-style buffers,
or 'stream' data with IIRC FF CR LF NL but not BS VT. IDRC HT.

 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      03-11-2013
David Thompson <(E-Mail Removed)> wrote:

(snip, someone wrote)
>> > If it's a conforming implementation of C, those characters must be
>> > supported: <snip 5.2.1p3, 5.2.2p2>


(snip, then I wrote)
>> The corresponding ASCII characters are reasonably well defined.


> Although the 'alternate' interpretation of LF as NL was often an issue
> -- quite a few terminals needed a switch/jumper/etc. for it.


I remember the Tektronix scope terminals with many possible combinations
that could be selected by jumper.

>> There is an EBCDIC backspace, so that should also work.


>> EBCDIC has CR, LF, and NL. I am not sure which one is used for '\n'
>> for EBCDIC C systems. I don't know of EBCDIC systems with a bell.
>> (There is a BEL control character, but I don't know what it does
>> on any system.)


>> The IBM 2741, the non-ASCII terminal most commonly used with IBM
>> mainframes, isn't EBCDIC. (It has its own character set based on
>> the position of the characters on the selectric type ball.)
>> As I remember, and as wikipedial says, there is no character
>> carriage return or bell character. There is BS, LF, and NL.


> And HT, although the tab stops were manually set and often wrong.


WYLBUR knows what to do with tabs, either on a 2741, or an ASCII
terminal with settable tabs. For data entry or normal listing,
there are columns for line numbers, so those aren't counted.
I did at least used to set a column 7 tab for Fortran programs,
and maybe also 73. SHO TABS VERIFY spaces out, printing a '1' at
each tab position, then tabs out and prints a '1'. If they line
up, you know that the tabs are set correctly. Especially nice for
entry or printing of tables. In normal use, WYLBUR doesn't store tabs
in a data set, but instead stores in its special blank compressed form.

> But I think 327X/328Xs were are at least as common as 2741's. And in
> practice all EBCDIC, although theoretically there were ASCII models to
> match S/360's not-really-usable PSW.ASCII bit.


Yes, I was thinking about the S/360 and early S/370 days. In later
years, the 327x were more popular. But 3270 and such are very different
from the usual serial terminals. For one, the controller does much of
the work that would, in the case of a usual serial terminal, be done by
the terminal. I believe that the data as sent to the controller is
EBCDIC, I am not so sure about what is actually sent to the 3270 itself,
especially in the case of control characters.

As well as I understand it, when the S/360 ASCII bit was used for the
EC mode bit on S/370, there were no IBM systems that ever used the bit.
It could only be set in supervisor mode. It is possible that some
non-IBM system could have set it.

But even so, it was not for the usual ASCII-7 (seven bit ASCII that we
all know), but a proposed but never used ASCII-8. ASCII-8 is not just
ASCII-7 with additional characters, but half of the characters
(I haven't looked at a table recently) were moved up. ASCII mode changes
the zones generated by UNPK, and the signs generated by decimal
instructions. All sign values are allowed as input to decimal
instructions, independent of the bit. Rather than use the mode bit, it
is usual to just change them after they are generated.

It might be that if ASCII-8 was standardized at the right time, that
IBM would have converted all of OS/360 over. That is, before there was
any installed base outside IBM. There are comments in the source for
the PL/I (F) compiler and library, in each source file, indicating that
it is either independent of the source character set, or if converted
to a different character set, will assembler in that character set.

To get back to C, some years ago someone sent be C source for a S/370
disassembler. It was pretty much impossible to use on an ASCII system,
and I only had ASCII systems available. There were many character
constants that would be used for printing messages, along with data
from the input program. But on an ASCII system, the constants are in
ASCII but the data was still in EBCDIC!. (Such as from %c or %s.)

I might have been able to do it by converting all character constants
to EBCDIC using \x escapes, then converting the EBCDIC output file back
to ASCII, but I hever did that.

> 327X displays use specialized meanings of DC1-4 ESC and I think one or
> two other controls. 328X printers could just use 327X-style buffers,
> or 'stream' data with IIRC FF CR LF NL but not BS VT. IDRC HT.


I barely ever used a 327x terminal, and never a printer for one.
I do have some of the manuals describing them, though. As well as I
know it, data is transfered a whole line, or even whole screen, at
a time. There are control characters to describe fields where data
entry is allowed, though, and the terminal (or controller) allows
one to modify such data, and for the host to read it back.

The result is a much lower interrupt overhead than is usual for ASCII
(or 2741) style terminals. It was also somewhat common to have a box
that emulated the 327x data stream on one side, and ASCII on the other,
(especially for remote terminals) such that users could have the 327x
experience with cheaper ASCII terminals.

-- glen
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-11-2013
glen herrmannsfeldt <(E-Mail Removed)> writes:
[...]
> But even so, it was not for the usual ASCII-7 (seven bit ASCII that we
> all know), but a proposed but never used ASCII-8. ASCII-8 is not just
> ASCII-7 with additional characters, but half of the characters
> (I haven't looked at a table recently) were moved up. ASCII mode changes
> the zones generated by UNPK, and the signs generated by decimal
> instructions. All sign values are allowed as input to decimal
> instructions, independent of the bit. Rather than use the mode bit, it
> is usual to just change them after they are generated.
>
> It might be that if ASCII-8 was standardized at the right time, that
> IBM would have converted all of OS/360 over. That is, before there was
> any installed base outside IBM. There are comments in the source for
> the PL/I (F) compiler and library, in each source file, indicating that
> it is either independent of the source character set, or if converted
> to a different character set, will assembler in that character set.

[...]

Interesting. Do you have a reference for this proposed ASCII-8?
It turns out to be difficult to Google; most of the references I've
found incorrectly refer to things like Latin-1 or Windows-1252 as
"8-bit ASCII".

If ASCII-8 had caught on, with some common characters requiring 8
bits, I wonder if UTF-8 would have been possible.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      03-11-2013
Keith Thompson <(E-Mail Removed)> wrote:

(snip, I wrote)

>> But even so, it was not for the usual ASCII-7 (seven bit ASCII that we
>> all know), but a proposed but never used ASCII-8. ASCII-8 is not just
>> ASCII-7 with additional characters, but half of the characters
>> (I haven't looked at a table recently) were moved up. ASCII mode changes
>> the zones generated by UNPK, and the signs generated by decimal
>> instructions. All sign values are allowed as input to decimal
>> instructions, independent of the bit. Rather than use the mode bit, it
>> is usual to just change them after they are generated.


>> It might be that if ASCII-8 was standardized at the right time, that
>> IBM would have converted all of OS/360 over. That is, before there was
>> any installed base outside IBM. There are comments in the source for
>> the PL/I (F) compiler and library, in each source file, indicating that
>> it is either independent of the source character set, or if converted
>> to a different character set, will assembler in that character set.

> [...]


> Interesting. Do you have a reference for this proposed ASCII-8?
> It turns out to be difficult to Google; most of the references I've
> found incorrectly refer to things like Latin-1 or Windows-1252 as
> "8-bit ASCII".


> If ASCII-8 had caught on, with some common characters requiring 8
> bits, I wonder if UTF-8 would have been possible.


Look in the Appendix of the S/360 Principles of Operation. Later
versions have a better description of it, such as the -7 (Dec 1967)
version from bitsavers.

There are still plenty of code points, they just moved them around.

Interesting also in the descirption is that ASCII bits are numbered
from 7 down to 1 (MSB to LSB) and EBCDIC from 0 to 7 (That is,
big-endian bit numbering for EBCDIC.)

Also interesting, IBM would have replaced the '^' with the "not" sign,
and the '!' with the vertical bar (logical OR) sign. (That is,
instead of the '|' character that most of us thing of as a vertical
bar, but which is actually a split vertical bar in ASCII.)
(It is split on the Dell keyboard I am using now, but not on the
screen display.)

-- glen

 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      03-12-2013
Robert Wessel <(E-Mail Removed)> wrote:

(snip, I wrote)
>>As well as I understand it, when the S/360 ASCII bit was used for the
>>EC mode bit on S/370, there were no IBM systems that ever used the bit.
>>It could only be set in supervisor mode. It is possible that some
>>non-IBM system could have set it.


> Yes. AFAIK, no non-IBM ever did, but it's always possible there was
> something obscure.


>>But even so, it was not for the usual ASCII-7 (seven bit ASCII that we
>>all know), but a proposed but never used ASCII-8. ASCII-8 is not just
>>ASCII-7 with additional characters, but half of the characters
>>(I haven't looked at a table recently) were moved up.


> You can see IBM's ASCII assignments on page 141 of:


> http://bitsavers.trailing-edge.com/p...60PrincOps.pdf


Yes, but the description is better in the -7 version.

-- glen
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Glorious Progress Back To The Past Lawrence D'Oliveiro NZ Computing 5 03-16-2011 11:47 AM
What is the point of having 16 bit colour if a computer monitor can only display 8 bit colour? How do you edit 16 bit colour when you can only see 8 bit? Scotius Digital Photography 6 07-13-2010 03:33 AM
Snow, glorious snow.....brings down the global warming fanatics richard Computer Support 10 02-07-2010 01:02 AM
Glorious USian broadband Lawrence D'Oliveiro NZ Computing 0 10-18-2007 12:53 AM
Another glorious blow against the reviled copyright violators Lawrence D'Oliveiro NZ Computing 1 05-21-2007 09:26 AM



Advertisments