{"thread":{"id":"9531","subject":"Need your help with MinGW Issue 17: --color options don't work (produce garbage)","startedAt":"2007-08-15T06:29:41Z","lastAt":"2007-08-21T14:08:27Z","messageCount":10,"participants":["Dmitry Kakurin","Reece Dunn","Johannes Schindelin","Rogan Dawes","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50754","messageId":"a1bbc6950708142329w4e0e3d7cq573c67dd3b28f03a@mail.gmail.com","threadId":"9531","inReplyTo":null,"subject":"Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-08-15T06:29:41Z","receivedAt":"2007-08-15T06:29:41Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"Here are the facts:\n\n'git branch --color' produces garbage:\n$ git branch --color\n  devel←[m\n  dima←[m\n  dmitryk←[m\n* ←[32mmaster←[m\n  mob←[m\n  next←[m\n\n'git branch --color | cat' produces expected colored output.\n\nI've traced it down to printf statement in gdb and it sends the right\nesc-sequence.\nWhere should I look next?\n\n(little bit) more info here:\nhttp://code.google.com/p/msysgit/issues/detail?id=17\n\n-- \n- Dmitry\n"},{"id":"50756","messageId":"3f4fd2640708150032l7441b285mc2cc9e22702bce21@mail.gmail.com","threadId":"9531","inReplyTo":"a1bbc6950708142329w4e0e3d7cq573c67dd3b28f03a@mail.gmail.com","subject":"Re: Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2007-08-15T07:32:35Z","receivedAt":"2007-08-15T07:32:35Z","isPatch":false,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"On 15/08/07, Dmitry Kakurin wrote:\n> Here are the facts:\n>\n> 'git branch --color' produces garbage:\n> $ git branch --color\n>   devel←[m\n>   dima←[m\n>   dmitryk←[m\n> * ←[32mmaster←[m\n>   mob←[m\n>   next←[m\n>\n> 'git branch --color | cat' produces expected colored output.\n>\n> I've traced it down to printf statement in gdb and it sends the right\n> esc-sequence.\n> Where should I look next?\n\nWindows doesn't recognise the *nix printf colour codes.\n\nPiping through cat will be going through cygwin/mingw emulation,\ntranslating the colour codes to the correct API calls.\n\nYou need to call the SetConsoleTextAttribute Win32 API. For example:\n\n#ifdef defined(WIN32) || defined(WIN64)\n\ntypedef WORD color_t;\n\ncolor_t red = FOREGROUND_INTENSITY | FOREGROUND_RED;\ncolor_t green = FOREGROUND_INTENSITY | FOREGROUND_GREEN;\ncolor_t blue = FOREGROUND_INTENSITY | FOREGROUND_BLUE;\n\ncolor_t white = red | green | blue;\n\nvoid set_color( color_t color )\n{\n    SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), color );\n}\n\n#else\n\ntypedef const char * color_t;\n\ncolor_t red = ...;\n...\n\nvoid set_color( color_t color ){ printf( color ); }\n\n#endif\n\nThat way, you can do things like:\n    set_color( red );\n    printf( ... );\n    set_color( blue );\n\nThis is not as pretty as the existing codebase, so another possibility\nwould be to create wrappers around the console output functions (i.e.\nprintf) and call SetConsoleTextAttribute there. This way, you can\nrestore the old colour when a restore settings sequence is\nintercepted. It is also possible to reuse the GetStdHandle return\nvalue.\n\nNOTE: There isn't a GetConsoleTextAttribute in the Windows API, but\nGoogle found this:\n\n#if ( (defined(WIN32) || defined(_WINDOWS)) && !defined(__CYGWIN__) )\n&& defined(_CONSOLE)\n\nstatic WORD GetConsoleTextAttribute(HANDLE Console)\n{\n    CONSOLE_SCREEN_BUFFER_INFO ConsoleInfo;\n    GetConsoleScreenBufferInfo(Console, &ConsoleInfo);\n    return ConsoleInfo.wAttributes;\n}\n\n#endif\n\nHTH,\n- Reece\n"},{"id":"50758","messageId":"a1bbc6950708150103v35330b47o781fb5d74e3d9aef@mail.gmail.com","threadId":"9531","inReplyTo":"3f4fd2640708150032l7441b285mc2cc9e22702bce21@mail.gmail.com","subject":"Re: [msysGit] Re: Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-08-15T08:03:25Z","receivedAt":"2007-08-15T08:03:25Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"On 8/15/07, Reece Dunn <msclrhd@googlemail.com> wrote:\n>\n> On 15/08/07, Dmitry Kakurin wrote:\n> > Here are the facts:\n> >\n> > 'git branch --color' produces garbage:\n> > $ git branch --color\n> >   devel←[m\n> >   dima←[m\n> >   dmitryk←[m\n> > * ←[32mmaster←[m\n> >   mob←[m\n> >   next←[m\n> >\n> > 'git branch --color | cat' produces expected colored output.\n> >\n> > I've traced it down to printf statement in gdb and it sends the right\n> > esc-sequence.\n> > Where should I look next?\n>\n> Windows doesn't recognise the *nix printf colour codes.\n>\n> Piping through cat will be going through cygwin/mingw emulation,\n> translating the colour codes to the correct API calls.\n\nThat's my question. If there is a way to build cat.exe to do this kind\nof emulation under MinGW then I should be able to do the same for\ngit.exe.\nI hope I just need to #define something while building Git.\nBut what is it?\n-- \n- Dmitry\n"},{"id":"50759","messageId":"3f4fd2640708150131o7578c2efy806891fc3def7429@mail.gmail.com","threadId":"9531","inReplyTo":"a1bbc6950708150103v35330b47o781fb5d74e3d9aef@mail.gmail.com","subject":"Re: [msysGit] Re: Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2007-08-15T08:31:21Z","receivedAt":"2007-08-15T08:31:21Z","isPatch":false,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"On 15/08/07, Dmitry Kakurin <dmitry.kakurin@gmail.com> wrote:\n> On 8/15/07, Reece Dunn <msclrhd@googlemail.com> wrote:\n> >\n> > On 15/08/07, Dmitry Kakurin wrote:\n> > > Here are the facts:\n> > >\n> > > 'git branch --color' produces garbage:\n> > > $ git branch --color\n> > >   devel←[m\n> > >   dima←[m\n> > >   dmitryk←[m\n> > > * ←[32mmaster←[m\n> > >   mob←[m\n> > >   next←[m\n> > >\n> > > 'git branch --color | cat' produces expected colored output.\n> > >\n> > > I've traced it down to printf statement in gdb and it sends the right\n> > > esc-sequence.\n> > > Where should I look next?\n> >\n> > Windows doesn't recognise the *nix printf colour codes.\n> >\n> > Piping through cat will be going through cygwin/mingw emulation,\n> > translating the colour codes to the correct API calls.\n>\n> That's my question. If there is a way to build cat.exe to do this kind\n> of emulation under MinGW then I should be able to do the same for\n> git.exe.\n> I hope I just need to #define something while building Git.\n> But what is it?\n\nYou will need to implement cat (or something similar) on MinGW that\nwill process the *nix colour codes and then pass that to\nSetConsoleTextAttributes. For example:\n\n    int ch = 0;\n    while(( ch = getch()) != EOF )\n    {\n        if( /*ch is part of a colour sequence*/ )\n        {\n            SetConsoleTextAttribute( GetStdHandle(...),\nwin_color_from_color_sequence(...));\n        }\n        else putc( ch );\n    }\n\nI don't believe that MinGW has got this working for cat, that is why\none that supports colours on Windows needs to be written.\n\n- Reece\n"},{"id":"50781","messageId":"Pine.LNX.4.64.0708151708570.19222@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"9531","inReplyTo":"3f4fd2640708150032l7441b285mc2cc9e22702bce21@mail.gmail.com","subject":"Re: [msysGit] Re: Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-15T15:10:05Z","receivedAt":"2007-08-15T15:10:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 15 Aug 2007, Reece Dunn wrote:\n\n> On 15/08/07, Dmitry Kakurin wrote:\n> > Here are the facts:\n> >\n> > 'git branch --color' produces garbage:\n> > $ git branch --color\n> >   devel??[m\n> >   dima??[m\n> >   dmitryk??[m\n> > * ??[32mmaster??[m\n> >   mob??[m\n> >   next??[m\n> >\n> > 'git branch --color | cat' produces expected colored output.\n> >\n> > I've traced it down to printf statement in gdb and it sends the right\n> > esc-sequence.\n> > Where should I look next?\n> \n> Windows doesn't recognise the *nix printf colour codes.\n> \n> Piping through cat will be going through cygwin/mingw emulation,\n> translating the colour codes to the correct API calls.\n> \n> You need to call the SetConsoleTextAttribute Win32 API. For example:\n> \n> #ifdef defined(WIN32) || defined(WIN64)\n> \n> typedef WORD color_t;\n> \n> color_t red = FOREGROUND_INTENSITY | FOREGROUND_RED;\n> color_t green = FOREGROUND_INTENSITY | FOREGROUND_GREEN;\n> color_t blue = FOREGROUND_INTENSITY | FOREGROUND_BLUE;\n> \n> color_t white = red | green | blue;\n> \n> void set_color( color_t color )\n> {\n>     SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), color );\n> }\n> \n> #else\n> \n> typedef const char * color_t;\n> \n> color_t red = ...;\n> ...\n> \n> void set_color( color_t color ){ printf( color ); }\n> \n> #endif\n> \n> That way, you can do things like:\n>     set_color( red );\n>     printf( ... );\n>     set_color( blue );\n> \n> This is not as pretty as the existing codebase, so another possibility\n> would be to create wrappers around the console output functions (i.e.\n> printf) and call SetConsoleTextAttribute there. This way, you can\n> restore the old colour when a restore settings sequence is\n> intercepted. It is also possible to reuse the GetStdHandle return\n> value.\n> \n> NOTE: There isn't a GetConsoleTextAttribute in the Windows API, but\n> Google found this:\n> \n> #if ( (defined(WIN32) || defined(_WINDOWS)) && !defined(__CYGWIN__) )\n> && defined(_CONSOLE)\n> \n> static WORD GetConsoleTextAttribute(HANDLE Console)\n> {\n>     CONSOLE_SCREEN_BUFFER_INFO ConsoleInfo;\n>     GetConsoleScreenBufferInfo(Console, &ConsoleInfo);\n>     return ConsoleInfo.wAttributes;\n> }\n> \n> #endif\n\nHmm.  Somehow I doubt that this hack works _outside_ of the Windows \nconsole.  I.e. if you call git in rxvt, it will fail, if you ssh into \nWindows, it will fail.\n\nCiao,\nDscho\n"},{"id":"50821","messageId":"46C36E7C.1080501@dawes.za.net","threadId":"9531","inReplyTo":"Pine.LNX.4.64.0708151708570.19222@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: [msysGit] Re: Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-08-15T21:22:04Z","receivedAt":"2007-08-15T21:22:04Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Johannes Schindelin wrote:\n\n> Hmm.  Somehow I doubt that this hack works _outside_ of the Windows \n> console.  I.e. if you call git in rxvt, it will fail, if you ssh into \n> Windows, it will fail.\n> \n> Ciao,\n> Dscho\n> \n\nI'd say that since Windows doesn't have the concept of terminfo or \nterminal types, and since SSH is mostly only supported through \ncygwin-style \"hacks\", (or F-Secure, but I have no experience with that) \nthat we should not be _too_ concerned about that.\n\nUsers that *do* need to use rxvt or SSH should simply disable the color \nmode, or alternatively, use the cygwin version. Color, while useful, is \nhardly critical functionality.\n\nMy R0.02.\n\nRegards,\n\nRogan\n"},{"id":"50823","messageId":"7vsl6ko51b.fsf@gitster.siamese.dyndns.org","threadId":"9531","inReplyTo":"46C36E7C.1080501@dawes.za.net","subject":"Re: [msysGit] Re: Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-15T21:34:56Z","receivedAt":"2007-08-15T21:34:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rogan Dawes <lists@dawes.za.net> writes:\n\n> Users that *do* need to use rxvt or SSH should simply disable the\n> color mode, or alternatively, use the cygwin version. Color, while\n> useful, is hardly critical functionality.\n\nHeh, that almost suggests that the native Windows command.com\nsupport can disable the color without upsetting anybody ;-)\n"},{"id":"50827","messageId":"46C37863.4020203@dawes.za.net","threadId":"9531","inReplyTo":"7vsl6ko51b.fsf@gitster.siamese.dyndns.org","subject":"Re: [msysGit] Re: Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-08-15T22:04:19Z","receivedAt":"2007-08-15T22:04:19Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Junio C Hamano wrote:\n> Rogan Dawes <lists@dawes.za.net> writes:\n> \n>> Users that *do* need to use rxvt or SSH should simply disable the\n>> color mode, or alternatively, use the cygwin version. Color, while\n>> useful, is hardly critical functionality.\n> \n> Heh, that almost suggests that the native Windows command.com\n> support can disable the color without upsetting anybody ;-)\n> \n\nIf that is the easiest way, yes.\n\nI *do* think that trying to get color working on the DOS cmdline is a \nworthy goal. I just don't think it is worth overcomplicating the issue \nand trying to handle rare corner cases such as someone SSHing into a \nWindows box, or running CMD inside rxvt.\n\nOne approach that might be more compatible with the existing escape code \napproach is to define the appropriate ANSI color escape sequences. Ah, a \nbit more googling shows that cmd.exe doesn't handle ANSI sequences in \nWindows NT and later.\n\nRegards,\n\nRogan\n"},{"id":"50829","messageId":"a1bbc6950708151507l15de5e9br5a09f13ad21d7f41@mail.gmail.com","threadId":"9531","inReplyTo":"3f4fd2640708150131o7578c2efy806891fc3def7429@mail.gmail.com","subject":"Re: [msysGit] Re: Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-08-15T22:07:18Z","receivedAt":"2007-08-15T22:07:18Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"On 8/15/07, Reece Dunn <msclrhd@googlemail.com> wrote:\n> I don't believe that MinGW has got this working for cat, that is why\n> one that supports colours on Windows needs to be written.\n\nMSys' cat does support colors even when I run it from cmd.exe.\nI've looked at sources for cat on mingw.sourceforge.com and (as\nexpected) there is no code to handle esc-sequences.\nThat would be insane - too many utilities like ls, diff, cat, less\netc. do that. So there is obviously a library for this.\nI've tried to \"parse\" makefiles for cat, but they are so huge and I\nknow about gcc/make on Unix so little that I was unable to find the\nsecret sauce.\nI've also asked this question on MinGW list so I'm waiting for reply.\n\n-- \n- Dmitry\n"},{"id":"51167","messageId":"46CAF1DB.3080305@dawes.za.net","threadId":"9531","inReplyTo":"7vsl6ko51b.fsf@gitster.siamese.dyndns.org","subject":"Re: [msysGit] Re: Need your help with MinGW Issue 17: --color options don't work (produce garbage)","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-08-21T14:08:27Z","receivedAt":"2007-08-21T14:08:27Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Junio C Hamano wrote:\n> Rogan Dawes <lists@dawes.za.net> writes:\n> \n>> Users that *do* need to use rxvt or SSH should simply disable the\n>> color mode, or alternatively, use the cygwin version. Color, while\n>> useful, is hardly critical functionality.\n> \n> Heh, that almost suggests that the native Windows command.com\n> support can disable the color without upsetting anybody ;-)\n> \n\nFollowing my other comment in this regard, another reason that colour in \nthe cmd line tools is less important, is because my impression of the \nintent of the Windows port (end goal, that is), is that the user will be \nable to use a Windows GUI front-end to do whatever it is they want to.\n\nAnd so the GUI front-end will be responsible for implementing the color \nanyway, most likely through pattern matching and a state machine.\n\nRegards,\n\nRogan\n"}]}