public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Sergei Gavrikov <w3sg@SoftHome.net>
To: Grant Edwards <grante@visi.com>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS]  Re: diag_printf refuses to print ANSI escape sequences?
Date: Mon, 28 May 2007 15:28:00 -0000	[thread overview]
Message-ID: <1180345081.16789.23.camel@sg-ubuntu> (raw)
In-Reply-To: <f3d5i2$k1o$1@sea.gmane.org>

В Вск, 27/05/2007 в 23:51 +0000, Grant Edwards пишет:
> 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.

I didn't speak about at all. I tried to say that diag_printf() hasn't to
become printf(). ABC is, If anyone need in full support for ANSI terms,
let he/she uses termcap/terminfo layer (for compatibility). eCos
printf() just quite prints such things:

printf ("Hello, \E[1meCos\E[m World!\n");

Why is here this flame? If you need to expand the diag_printf() add own
CDL rule to expand that diag_check_string ():

if( c == '\n' || c == '\r' || c == '\b' || c == '\t' || c == '\E' )
    continue;

Gary already did point on that.

regards,

--Sergei

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

  reply	other threads:[~2007-05-28  9:39 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
2007-05-28 15:28         ` Sergei Gavrikov [this message]
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=1180345081.16789.23.camel@sg-ubuntu \
    --to=w3sg@softhome.net \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=grante@visi.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).