Need your help with MinGW Issue 17: --color options don't work (produce garbage)

瀏覽次數:92 次
跳到第一則未讀訊息

Dmitry Kakurin

未讀,
2007年8月15日 凌晨2:29:412007/8/15
收件者:msysGit、Git Mailing List
Here are the facts:

'git branch --color' produces garbage:
$ git branch --color
devel←[m
dima←[m
dmitryk←[m
* ←[32mmaster←[m
mob←[m
next←[m

'git branch --color | cat' produces expected colored output.

I've traced it down to printf statement in gdb and it sends the right
esc-sequence.
Where should I look next?

(little bit) more info here:
http://code.google.com/p/msysgit/issues/detail?id=17

--
- Dmitry

Reece Dunn

未讀,
2007年8月15日 凌晨3:32:352007/8/15
收件者:msysGit、Git Mailing List
On 15/08/07, Dmitry Kakurin wrote:
> Here are the facts:
>
> 'git branch --color' produces garbage:
> $ git branch --color
> devel←[m
> dima←[m
> dmitryk←[m
> * ←[32mmaster←[m
> mob←[m
> next←[m
>
> 'git branch --color | cat' produces expected colored output.
>
> I've traced it down to printf statement in gdb and it sends the right
> esc-sequence.
> Where should I look next?

Windows doesn't recognise the *nix printf colour codes.

Piping through cat will be going through cygwin/mingw emulation,
translating the colour codes to the correct API calls.

You need to call the SetConsoleTextAttribute Win32 API. For example:

#ifdef defined(WIN32) || defined(WIN64)

typedef WORD color_t;

color_t red = FOREGROUND_INTENSITY | FOREGROUND_RED;
color_t green = FOREGROUND_INTENSITY | FOREGROUND_GREEN;
color_t blue = FOREGROUND_INTENSITY | FOREGROUND_BLUE;

color_t white = red | green | blue;

void set_color( color_t color )
{
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), color );
}

#else

typedef const char * color_t;

color_t red = ...;
...

void set_color( color_t color ){ printf( color ); }

#endif

That way, you can do things like:
set_color( red );
printf( ... );
set_color( blue );

This is not as pretty as the existing codebase, so another possibility
would be to create wrappers around the console output functions (i.e.
printf) and call SetConsoleTextAttribute there. This way, you can
restore the old colour when a restore settings sequence is
intercepted. It is also possible to reuse the GetStdHandle return
value.

NOTE: There isn't a GetConsoleTextAttribute in the Windows API, but
Google found this:

#if ( (defined(WIN32) || defined(_WINDOWS)) && !defined(__CYGWIN__) )
&& defined(_CONSOLE)

static WORD GetConsoleTextAttribute(HANDLE Console)
{
CONSOLE_SCREEN_BUFFER_INFO ConsoleInfo;
GetConsoleScreenBufferInfo(Console, &ConsoleInfo);
return ConsoleInfo.wAttributes;
}

#endif

HTH,
- Reece

Dmitry Kakurin

未讀,
2007年8月15日 凌晨4:03:252007/8/15
收件者:msc...@googlemail.com、msysGit、Git Mailing List
On 8/15/07, Reece Dunn <msc...@googlemail.com> wrote:
>
> On 15/08/07, Dmitry Kakurin wrote:
> > Here are the facts:
> >
> > 'git branch --color' produces garbage:
> > $ git branch --color
> > devel←[m
> > dima←[m
> > dmitryk←[m
> > * ←[32mmaster←[m
> > mob←[m
> > next←[m
> >
> > 'git branch --color | cat' produces expected colored output.
> >
> > I've traced it down to printf statement in gdb and it sends the right
> > esc-sequence.
> > Where should I look next?
>
> Windows doesn't recognise the *nix printf colour codes.
>
> Piping through cat will be going through cygwin/mingw emulation,
> translating the colour codes to the correct API calls.

That's my question. If there is a way to build cat.exe to do this kind
of emulation under MinGW then I should be able to do the same for
git.exe.
I hope I just need to #define something while building Git.
But what is it?
--
- Dmitry

Reece Dunn

未讀,
2007年8月15日 凌晨4:31:212007/8/15
收件者:Dmitry Kakurin、msysGit、Git Mailing List

You will need to implement cat (or something similar) on MinGW that
will process the *nix colour codes and then pass that to
SetConsoleTextAttributes. For example:

int ch = 0;
while(( ch = getch()) != EOF )
{
if( /*ch is part of a colour sequence*/ )
{
SetConsoleTextAttribute( GetStdHandle(...),
win_color_from_color_sequence(...));
}
else putc( ch );
}

I don't believe that MinGW has got this working for cat, that is why
one that supports colours on Windows needs to be written.

- Reece

Johannes Schindelin

未讀,
2007年8月15日 上午11:10:052007/8/15
收件者:Reece Dunn、msysGit、Git Mailing List
Hi,

On Wed, 15 Aug 2007, Reece Dunn wrote:

> On 15/08/07, Dmitry Kakurin wrote:
> > Here are the facts:
> >
> > 'git branch --color' produces garbage:
> > $ git branch --color

> > devel??[m
> > dima??[m
> > dmitryk??[m
> > * ??[32mmaster??[m
> > mob??[m
> > next??[m

Hmm. Somehow I doubt that this hack works _outside_ of the Windows
console. I.e. if you call git in rxvt, it will fail, if you ssh into
Windows, it will fail.

Ciao,
Dscho

Rogan Dawes

未讀,
2007年8月15日 下午5:22:042007/8/15
收件者:Johannes Schindelin、Reece Dunn、msysGit、Git Mailing List
Johannes Schindelin wrote:

> Hmm. Somehow I doubt that this hack works _outside_ of the Windows
> console. I.e. if you call git in rxvt, it will fail, if you ssh into
> Windows, it will fail.
>
> Ciao,
> Dscho
>

I'd say that since Windows doesn't have the concept of terminfo or
terminal types, and since SSH is mostly only supported through
cygwin-style "hacks", (or F-Secure, but I have no experience with that)
that we should not be _too_ concerned about that.

Users that *do* need to use rxvt or SSH should simply disable the color
mode, or alternatively, use the cygwin version. Color, while useful, is
hardly critical functionality.

My R0.02.

Regards,

Rogan

Junio C Hamano

未讀,
2007年8月15日 下午5:34:562007/8/15
收件者:Rogan Dawes、Johannes Schindelin、Reece Dunn、msysGit、Git Mailing List
Rogan Dawes <li...@dawes.za.net> writes:

> Users that *do* need to use rxvt or SSH should simply disable the
> color mode, or alternatively, use the cygwin version. Color, while
> useful, is hardly critical functionality.

Heh, that almost suggests that the native Windows command.com
support can disable the color without upsetting anybody ;-)

Rogan Dawes

未讀,
2007年8月15日 下午6:04:192007/8/15
收件者:Junio C Hamano、Johannes Schindelin、Reece Dunn、msysGit、Git Mailing List

If that is the easiest way, yes.

I *do* think that trying to get color working on the DOS cmdline is a
worthy goal. I just don't think it is worth overcomplicating the issue
and trying to handle rare corner cases such as someone SSHing into a
Windows box, or running CMD inside rxvt.

One approach that might be more compatible with the existing escape code
approach is to define the appropriate ANSI color escape sequences. Ah, a
bit more googling shows that cmd.exe doesn't handle ANSI sequences in
Windows NT and later.

Regards,

Rogan

Dmitry Kakurin

未讀,
2007年8月15日 下午6:07:182007/8/15
收件者:Reece Dunn、msysGit、Git Mailing List
On 8/15/07, Reece Dunn <msc...@googlemail.com> wrote:
> I don't believe that MinGW has got this working for cat, that is why
> one that supports colours on Windows needs to be written.

MSys' cat does support colors even when I run it from cmd.exe.
I've looked at sources for cat on mingw.sourceforge.com and (as
expected) there is no code to handle esc-sequences.
That would be insane - too many utilities like ls, diff, cat, less
etc. do that. So there is obviously a library for this.
I've tried to "parse" makefiles for cat, but they are so huge and I
know about gcc/make on Unix so little that I was unable to find the
secret sauce.
I've also asked this question on MinGW list so I'm waiting for reply.

--
- Dmitry

Rogan Dawes

未讀,
2007年8月21日 上午10:08:272007/8/21
收件者:Junio C Hamano、Johannes Schindelin、Reece Dunn、msysGit、Git Mailing List

Following my other comment in this regard, another reason that colour in
the cmd line tools is less important, is because my impression of the
intent of the Windows port (end goal, that is), is that the user will be
able to use a Windows GUI front-end to do whatever it is they want to.

And so the GUI front-end will be responsible for implementing the color
anyway, most likely through pattern matching and a state machine.

Regards,

Rogan

回覆所有人
回覆作者
轉寄
0 則新訊息