From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10159 invoked by alias); 28 May 2007 09:39:15 -0000 Received: (qmail 10146 invoked by uid 22791); 28 May 2007 09:39:14 -0000 X-Spam-Check-By: sourceware.org Received: from jive.SoftHome.net (HELO jive.SoftHome.net) (66.54.152.27) by sourceware.org (qpsmtpd/0.31) with SMTP; Mon, 28 May 2007 09:39:12 +0000 Received: (qmail 1602 invoked by uid 417); 28 May 2007 09:38:51 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 28 May 2007 09:38:51 -0000 Received: from [192.168.0.33] ([82.209.212.146]) (AUTH: PLAIN w3sg@softhome.net) by softhome.net with esmtp; Mon, 28 May 2007 03:38:18 -0600 From: Sergei Gavrikov To: Grant Edwards Cc: ecos-discuss@ecos.sourceware.org In-Reply-To: References: <20070526163810.GA13155@ubuntu> <20070527101131.GA8574@ubuntu> Content-Type: text/plain; charset=UTF-8 Date: Mon, 28 May 2007 15:28:00 -0000 Message-Id: <1180345081.16789.23.camel@sg-ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences? X-SW-Source: 2007-05/txt/msg00142.txt.bz2 В Вск, 27/05/2007 в 23:51 +0000, Grant Edwards пишет: > On 2007-05-27, Sergei Gavrikov 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