«

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

Le 01/03/2013 11:04, Malcolm McLean a écrit :
> How widely supported are the escape ... m colour codes for text?

This is not a C-related question, but it depends on your terminal
capabilities (ie. TERM environment variable on Unix ; man -i 5
terminfo). Most Unix flavor terminal have vt220 flavored escape sequence
support (http://en.wikipedia.org/wiki/ANSI_escape_code), for example.

You may want to use a more abstract way to do that, however (such as
http://en.wikipedia.org/wiki/Curses_...ing_library%29)

"Malcolm McLean" <> wrote in message
news:f53f10fd-9d24-44ae-ae46-...
> How widely supported are the escape ... m colour codes for text?

They don't seem to work under Windows unless you have something like
'ansicon' installed (but which introduces problems of its own.)

--
Bartc

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.

Any Unix system will have either or both of those libraries. The Windows
console doesn't support escape sequences.

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.

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.

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: "In the basic execution character set, there shall be control
characters representing alert, backspace, carriage return, and new
line." (5.2.1p3). If it's not a conforming implementation, there's no
limit to how far it's failure to conform can go, so there's not much
point in talking about it here. The associated semantics are covered by
5.2.2p2:

"Alphabetic escape sequences representing nongraphic characters in the
execution character set are intended to produce actions on display
devices as follows:
\a (alert) Produces an audible or visible alert without changing the
active position.
\b (backspace) Moves the active position to the previous position on the
current line. If
....
\r (carriage return) Moves the active position to the initial position
of the current line."

Of course, "are intended to produce" is sufficiently vague to allow
implementations that don't meaningfully implement the specified semantics.

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: "In the basic execution character set, there shall be control
> characters representing alert, backspace, carriage return, and new
> line." (5.2.1p3). If it's not a conforming implementation, there's no
> limit to how far it's failure to conform can go, so there's not much
> point in talking about it here. The associated semantics are covered by
> 5.2.2p2:

The corresponding ASCII characters are reasonably well defined.

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.

-- glen

On Fri, 01 Mar 2013 06:13:55 -0800, Malcolm McLean 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.

This is going off-topic for c.l.c, but there might be a possibility to
control the programs that produce the output.
In Unix-like systems, it is very common to redirect the output from one
program to another program, and the programs are not expected to be able
to handle escape sequences.
Because of this, most (all?) programs that can produce colorized console-
output will do so only if they determine that their output goes to an
interactive terminal.
It might be worth it to investigate if the Linux-side of your remote
console can act as a non-interactive device.

Bart v Ingen Schenau

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

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

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