From: Grant Edwards <grante@visi.com>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] Re: diag_printf refuses to print ANSI escape sequences?
Date: Mon, 28 May 2007 05:33:00 -0000 [thread overview]
Message-ID: <f3d5i2$k1o$1@sea.gmane.org> (raw)
In-Reply-To: <20070527101131.GA8574@ubuntu>
On 2007-05-27, Sergei Gavrikov <w3sg@SoftHome.net> wrote:
>> I'm aware of the daig_dump_buf fuctions, but I don't see how
>> they solve my problem. AFAIR, they dump out buffer contents in
>> hex. What I'm trying to do is:
>>
>> diag_printf("\033[34mBlue Text \033[31mRed Text \033[mNormal Text\n");
>>
>> diag_printf refuses to do that, so I have to do something like
>> this instead:
>>
>> diag_printf("%c[34mBlue Text %c[31mRed Text %c[mNormal Text\n",033,033,033);
>>
>> and that seems awkward to me.
>>
>> One could argue that embedding escape seqences in strings is a
>> bit hackish...
>
> Ah, the diag_printf() for me always did mean the diagnostic (read debug)
> output function, but it didn't mean for me any type of the printf+send.
> IMHO, those diag_*() functions should be the light weight things.
Then adding extra code to reject strings with escape character
in them seems to be the wrong way to go them.
> I wouldn't see the complex parsing in the diag_printf(),
> diag_sprintf() functions.
I don't understand. Are you don't think there shouldn't be
formatted diagnostic output?
> What's about falk which use the eCos minimal template in the
> first?
I've no idea.
> It seems, it's easy to use either macros, for example,
> COLOR_PRINTF, COLOR_PUTS, etc. something like this
>
> #define COLOR_PRINTF( fgcolor, bgcolor, fmt, ...) \
> ...
>
> and to use the diag_write_char() in the body of the macro to
> output those special characters, or just own whiptail
> functions, i.e. something like the cprintf(), cputchar(),
> cputs().
I know there are other ways to accomplish what I want. I was
just surprised because even full-blown "regular" printf
functions (e.g. under Windows or Linux) don't include code to
reject strings with escape characters in them. So I was
surprised that a lightweight printf function to have that added
feature. It's not a big deal as I'm done with the program in
which I wanted color output -- I was just surprised that it
worked the way it does.
> But the question is staying for me, Is the colorized output
> deal for diag_printf?
I almost never have a diagnostic port connected to anything
that's not a (mostly) ANSI terminal. 99% of the time I don't
really have much use for color output.
> I know that there are dumb terminals,
I couldn't find a dumb terminal if I wanted to (unless you want
to count minicom, which is broken in enough ways that I'd
probably classify it as dumb).
> GDB, etc. there. Those things are deal for diag_printf(),
> aren't they?
I don't have any dumb terminals, all I've got are ANSI ones. It
was just some output from a test program I was using to
troubleshoot some hardware. It doesn't have to be portable.
> IMHO, diag_led can produce the colorized output,
No it can't. Not on my platform.
> but diag_printf shouldn't do such things :-)
Since most of the people on Earth don't read English and don't
use a Latin alphabet, it probably shouldn't produce English or
be using a Latin alphabet either.
--
Grant Edwards grante Yow! I want another
at RE-WRITE on my CEASAR
visi.com SALAD!!
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next prev parent reply other threads:[~2007-05-27 23:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-26 16:38 [ECOS] " Grant Edwards
2007-05-26 20:19 ` Sergei Gavrikov
2007-05-26 22:56 ` [ECOS] " Grant Edwards
2007-05-27 10:12 ` Gary Thomas
2007-05-27 14:42 ` Sergei Gavrikov
2007-05-28 5:33 ` Grant Edwards [this message]
2007-05-28 15:28 ` Sergei Gavrikov
2007-05-28 20:22 ` Paul D. DeRocco
2007-05-28 20:33 ` Sergei Gavrikov
2007-05-29 4:50 ` Paul D. DeRocco
2007-05-29 9:57 ` Nick Garnett
2007-05-29 17:05 ` Grant Edwards
2007-05-29 7:45 David Fernandez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='f3d5i2$k1o$1@sea.gmane.org' \
--to=grante@visi.com \
--cc=ecos-discuss@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).