MinGW - Minimalist GNU for Windows

Hi Vincent,

On Fri, 26 Mar 2010, Vincent Torri wrote:

> When I use SetConsoleTextAttribute() with MSYS without rxvt emulation, I
> can change the colors of the text. When I use MSYS with rxvt emulation,
> this function does not change the color (though the escaped codes are
> working). Is it normal ? (note that i know that you (mingw/msys devs) do
> not encourage its use)

As far as I know, SetConsoleTextAttribute only works (has any effect) on 
cmd.exe and derivatives, which doesn't include rxvt, which uses ANSI 
escape codes to change colours instead.

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

Hey,

>> When I use SetConsoleTextAttribute() with MSYS without rxvt emulation, I
>> can change the colors of the text. When I use MSYS with rxvt emulation,
>> this function does not change the color (though the escaped codes are
>> working). Is it normal ? (note that i know that you (mingw/msys devs) do
>> not encourage its use)
>
> As far as I know, SetConsoleTextAttribute only works (has any effect) on
> cmd.exe and derivatives, which doesn't include rxvt, which uses ANSI
> escape codes to change colours instead.

ok, thank you. Now, if someone use rxvt, the escape codes must be used. I 
would like though to forbid their use if, for example, redirection or pipe 
is used. So:

./test_log.exe

displays colored text.

./tst_log.exe > log.txt

does not display colored text (otherwise log.txt would contain text and 
escape codes).

On linux, it can be done by testing a fd and by using isatty(). Is it 
possible to do something similar with MSYS with rxvt emulation ?

thank you

Vincent Torri

> As far as I know, SetConsoleTextAttribute only works (has any effect) on cmd.exe,

Better to say, it has effect only on console windows. (As one can see
from its name.)

Cmd.exe is just a program that often is run in a console window, but
it isn't cmd.exe that implements the functionality of a console
window.

(On Windows 7, the process that implements console window
functionality is conhost.exe, and earlier it was implemented directly
by csrss.exe, the Win32 subsystem. No doubt is csrss.exe still
involved in some way but not as directly as before.)

When for instance bash.exe is running in a console window, no cmd.exe
is involved but bash or some console executable started from bash (and
thus using the same console window) can use console API successfully.
And the other way around, you can run cmd.exe in a rxvt window but no
console window is then used and console APIs will fail.

--tml

Vincent Torri wrote:

>
>  On linux, it can be done by testing a fd and by using isatty(). Is it
>   possible to do something similar with MSYS with rxvt emulation ?
>

No, because it is impossible to correctly emulate PTY on Windows making 
isatty() not work properly.

-- 
Earnie
-- http://www.for-my-kids.com

On Fri, 26 Mar 2010, Earnie wrote:

>>  On linux, it can be done by testing a fd and by using isatty(). Is it
>>   possible to do something similar with MSYS with rxvt emulation ?
>>
>
> No, because it is impossible to correctly emulate PTY on Windows making
> isatty() not work properly.

and using something else than isatty() ? I want to be able to know if 
there is a redirection (by using > or a pipe, for example).

Vincent Torri

On Friday 26 March 2010 20:03:13 Vincent Torri wrote:
> >>  On linux, it can be done by testing a fd and by using
> >> isatty(). Is it possible to do something similar with MSYS with
> >> rxvt emulation ?
> >
> > No, because it is impossible to correctly emulate PTY on Windows
> > making isatty() not work properly.
>
> and using something else than isatty() ? I want to be able to know
> if there is a redirection (by using > or a pipe, for example).

AFAIK, if you insist on using RXVT, there is no way for you to do 
this; that's one of the reasons -- perhaps the principal reason -- 
why we try to discourage its use.

Just out of curiosity, WHY do you insist on using RXVT?  isatty() 
works fine in a standard MS-Windows console, so using that is the 
only advice I will offer.  If it's simply that you dislike the 
appearance of the native console, there is plenty of previously 
posted advice on making it look better than its defaults.  If you 
need the ability to resize on the fly, then try Console2, (a 
separate SourceForge project); it gives you a standard console with 
a vastly improved user visible interface.

-- 
Regards,
Keith.

On Fri, 26 Mar 2010, Keith Marshall wrote:

>> and using something else than isatty() ? I want to be able to know
>> if there is a redirection (by using > or a pipe, for example).
>
> AFAIK, if you insist on using RXVT, there is no way for you to do
> this; that's one of the reasons -- perhaps the principal reason --
> why we try to discourage its use.
>
> Just out of curiosity, WHY do you insist on using RXVT?  isatty()
> works fine in a standard MS-Windows console, so using that is the
> only advice I will offer.  If it's simply that you dislike the
> appearance of the native console, there is plenty of previously
> posted advice on making it look better than its defaults.  If you
> need the ability to resize on the fly, then try Console2, (a
> separate SourceForge project); it gives you a standard console with
> a vastly improved user visible interface.

I'm porting a library that displays log messages in the console. The 
messages can be colored. I just want to also support the rxvt emulation. 
If it's too much work or not possible, i'll give up. There will be no 
colored message with that console.

thank you for your answer

Vincent Torri

On Saturday 27 March 2010 03:03:20 Vincent Torri wrote:
> I'm porting a library that displays log messages in the console.
> The messages can be colored. I just want to also support the rxvt
> emulation. If it's too much work or not possible, i'll give up.
> There will be no colored message with that console.

MSYS' rxvt connects your application's stdin, stdout and stderr to 
its own I/O processing interface via pipes.  A pipe is no more than 
a generic file stream; there is no way your application can identify 
it as anything else.

AFAIK Cygwin's rxvt exhibits the same behaviour, when running any 
native MS-Windows (i.e. non-Cygwin) application; (of course, the 
Cygwin folks never seemed to promote the use of rxvt to the extent 
MSYS used to).

Charles Wilson, who AFAIK maintains rxvt for both Cygwin and for 
MSYS, recently said he would like it to die on both platforms.  I 
gave it up as a lost cause, long ago; I suggest you do so too.

-- 
Regards,
Keith.

On 27 March 2010 08:15, Keith Marshall wrote:
> On Saturday 27 March 2010 03:03:20 Vincent Torri wrote:
>> I'm porting a library that displays log messages in the console.
>> The messages can be colored. I just want to also support the rxvt
>> emulation. If it's too much work or not possible, i'll give up.
>> There will be no colored message with that console.
>
> MSYS' rxvt connects your application's stdin, stdout and stderr to
> its own I/O processing interface via pipes.  A pipe is no more than
> a generic file stream; there is no way your application can identify
> it as anything else.
>
> AFAIK Cygwin's rxvt exhibits the same behaviour, when running any
> native MS-Windows (i.e. non-Cygwin) application

That's true, but the issue has much less impact on Cygwin, because
people primarily run (and write) Unix applications linked against the
Cygwin DLL there. With that, isatty() and escape sequences work fine
both in console windows and in pty-based terminals like rxvt.


> (of course, the
> Cygwin folks never seemed to promote the use of rxvt to the extent
> MSYS used to).

When the issue does come up, the answer is to either use the Cygwin
version of the program in question where applicable, or to use the
console (which apart from its UI shortcomings also has some functional
limitations when used as a Unix terminal).


> Charles Wilson, who AFAIK maintains rxvt for both Cygwin and for
> MSYS, recently said he would like it to die on both platforms.

I think the main reason for that is that it's dead upstream. Also, in
Cygwin 1.7's case, its lack of UTF-8 support. The replacements are
rxvt-unicode (also maintained by Charles Wilson) for users running an
X server, and mintty, which doesn't need X.

(Btw, I created mintty by combining bits of PuTTY with Cygwin ptys and
I did have a look at porting it to MSYS. I decided not to, though, due
to the very issue discussed here. It's not just direct invocations of
console-specific functions as in Vincent's example that are a problem,
but also MSVCRT functions like isatty() that depend on the program
running in a console. So I agree, Console2's approach of putting a
nicer interface on a hidden console is more suited for MinGW
programs.)

Regards,
Andy

On 3/27/2010 7:31 AM, Andy Koppe wrote:
> So I agree, Console2's approach of putting a
> nicer interface on a hidden console is more suited for Mingw

I know that we have a policy concerning not distributing applications
that can't be built using free-as-in-speech tools, even if the
application itself is open source.  However, maybe it would be
acceptable for us to include in msysCORE a helper script:

get-console2.sh

that would download and install, into /mingw/bin (or /bin, if no /mingw
mount point or directory exists), the latest console2 executable. The
script could also automatically configure an XML configuration for it,
and create shortcuts for both "MinGW" (cmd shell with proper env vars
for using MingGW gcc), "MSYS" (bash shell for MinGW development), and
optionally MSYS-DVLPR personalities.

Is that idea worth looking into?  Yeah, it's a little hypocritical to
promote the use of a tool we won't personally distribute for religious
reasons, but...darnitall, rxvt just needs to go away.

--
Chuck

Charles Wilson wrote:
>  On 3/27/2010 7:31 AM, Andy Koppe wrote:
> > So I agree, Console2's approach of putting a nicer interface on a
> > hidden console is more suited for Mingw
>
>  I know that we have a policy concerning not distributing
>  applications that can't be built using free-as-in-speech tools, even
>  if the application itself is open source.  However, maybe it would
>  be acceptable for us to include in msysCORE a helper script:
>
>  get-console2.sh
>

Or maybe someone would be willing to put the work into making this 
console2 app build with MinGW tools?  Anyone willing to give it a try?

-- 
Earnie
-- http://www.for-my-kids.com

On 3/27/2010 11:27 AM, Earnie wrote:
> Or maybe someone would be willing to put the work into making this 
> console2 app build with MinGW tools?  Anyone willing to give it a try?

IIRC Keith already did -- and gave it up as a bad idea.  I think it
requires a lot of additions to the w32api libraries for which we don't
have public domain information.

--
Chuck

On 3/27/2010 10:23 AM, Charles Wilson wrote:
> However, maybe it would be
> acceptable for us to include in msysCORE a helper script:
> 
> get-console2.sh
> 
> that would download and install, into /mingw/bin (or /bin, if no /mingw
> mount point or directory exists), the latest console2 executable. The
> script could also automatically configure an XML configuration for it,
> and create shortcuts for both "MinGW" (cmd shell with proper env vars
> for using MingGW gcc), "MSYS" (bash shell for MinGW development), and
> optionally MSYS-DVLPR personalities.

I've got a working implementation of this, but it requires the new
msys-wget and msys-unzip packages (which I have not yet uploaded to
sourceforge).

It seems to work pretty well, though.  It:
  a) downloads the binary .zip from sourceforge
  b) unpacks it into /usr/lib/Console2/
  c) creates a customized console.xml configuration (sed'ing in the
     msys root directory and stuff).
  d) creates a shortcut that can start up console+msys (bypassing
     msys.bat).

I've attached the "input" console.xml file, so that people can suggest
changes for the default behavior/key accels (I think Keith has some
opinions on this).

Note that the script allows the user to specify the font, but not yet
the fontsize.  E.g. right now you can:

  console2-config -f 'Consolas'

if you hate the default Lucida Console.

Anyway, grep for '@@' to see the customizable settings, and please
suggest (a) other 'hardcoded' setting we should include, and (b) other
'customizable' settings that the script should allow the end-user to
specify, via options as demonstrated above.


===========================================================
console2-config [-c DIR] [-f FONT] [-A] [-D] [-P SDIR]
  Download, install, and configure Console2 for
  use with MinGW/MSYS.

Options:
  -h       Show this help
  -c DIR   Include cygwin configuration. DIR must
           be the msys path to the root of the cygwin
           installation. E.g. '/c/cygwin'
  -f FONT  Specify the font. Defaults to Lucida Console
           but 'Consolas', 'Courier New', or
           'DejaVu LGC Sans Mono' are also good choices
  -A       Use 'All Users' instead of current user for -D,-P
  -D       Create shortcut on the 'Desktop'
  -P SDIR  Create shortcut in the specified subdirectory of
           the Start Menu 'Programs' directory

See https://sourceforge.net/projects/console/
===========================================================

(FWIW, -A doesn't work unless you have admin rights, and neither -A nor
-P work very well on Vista or W7 if UAC is active. But... -D is fine,
and the default behavior simply creates the short cut in the user's home
directory, and he can move it from there to where-ever he likes)

--
Chuck

On Tuesday 20 April 2010 01:03:57 Charles Wilson wrote:
> I've got a working implementation of this, but it requires the new
> msys-wget and msys-unzip packages (which I have not yet uploaded
> to sourceforge).
>
> It seems to work pretty well, though.  It:
>   a) downloads the binary .zip from sourceforge
>   b) unpacks it into /usr/lib/Console2/
>   c) creates a customized console.xml configuration (sed'ing in
> the msys root directory and stuff).
>   d) creates a shortcut that can start up console+msys (bypassing
>      msys.bat).

That's the way I use it too.

> I've attached the "input" console.xml file, so that people can
> suggest changes for the default behavior/key accels (I think Keith
> has some opinions on this).

Yes.  I won't say that my setup, (which mostly emulates the primary 
key bindings of KDE's Konsole), will be right for everyone, but some 
of the defaults coming from the upstream project are badly chosen, 
(particularly when deploying with an MSYS shell):--

* ^S brings up the "settings dialogue".  NOT just an MSYS issue; it
  interferes with XON/XOFF in anything which might use it.

* ^D dumps something, IIRC, (but I can't remember exactly what);
  interferes with MSYS EOF signalling.

...are just two examples which immediately spring to mind.

FWIW, I've attached a copy of my own console.xml configuration.

-- 
Regards,
Keith.

On 4/20/2010 5:28 PM, Keith Marshall wrote:
> FWIW, I've attached a copy of my own console.xml configuration.

Yes, I think mine was based on an older version you posted. Here are the
only non-cosmetic differences between what I posted yesterday and yours
today:

-chuck
+keith
@@ -68,17 +68,15 @@
     <hotkey ctrl="1" shift="0" alt="0" extended="1" code="45"
command="copy"/>
     <hotkey ctrl="1" shift="0" alt="0" extended="1" code="46"
command="clear_selection"/>
     <hotkey ctrl="0" shift="1" alt="0" extended="1" code="45"
command="paste"/>
-    <hotkey ctrl="0" shift="0" alt="0" extended="0" code="0"
command="stopscroll"/>
-    <hotkey ctrl="1" shift="1" alt="0" extended="1" code="38"
command="scrollrowup"/>
-    <hotkey ctrl="1" shift="1" alt="0" extended="1" code="40"
command="scrollrowdown"/>
-    <hotkey ctrl="1" shift="1" alt="0" extended="1" code="33"
command="scrollpageup"/>
-    <hotkey ctrl="1" shift="1" alt="0" extended="1" code="34"
command="scrollpagedown"/>
-    <hotkey ctrl="0" shift="0" alt="0" extended="0" code="0"
command="scrollcolleft"/>
-    <hotkey ctrl="0" shift="0" alt="0" extended="0" code="0"
command="scrollcolright"/>
-    <hotkey ctrl="0" shift="0" alt="0" extended="0" code="0"
command="scrollpageleft"/>
-    <hotkey ctrl="0" shift="0" alt="0" extended="0" code="0"
command="scrollpageright"/>
+               <hotkey ctrl="0" shift="1" alt="0" extended="1"
code="38" command="scrollrowup"/>
+               <hotkey ctrl="0" shift="1" alt="0" extended="1"
code="40" command="scrollrowdown"/>
+               <hotkey ctrl="0" shift="1" alt="0" extended="1"
code="33" command="scrollpageup"/>
+               <hotkey ctrl="0" shift="1" alt="0" extended="1"
code="34" command="scrollpagedown"/>
+               <hotkey ctrl="1" shift="1" alt="0" extended="1"
code="37" command="scrollcolleft"/>
+               <hotkey ctrl="1" shift="1" alt="0" extended="1"
code="39" command="scrollcolright"/>
+               <hotkey ctrl="0" shift="1" alt="1" extended="1"
code="37" command="scrollpageleft"/>
+               <hotkey ctrl="0" shift="1" alt="1" extended="1"
code="39" command="scrollpageright"/>
     <hotkey ctrl="1" shift="0" alt="1" extended="0" code="68"
command="dumpbuffer"/>
-    <hotkey ctrl="0" shift="0" alt="0" extended="0" code="0"
command="activate"/>
   </hotkeys>

Op 20-04-10 23:28, Keith Marshall schreef:
>> I've attached the "input" console.xml file, so that people can
>> suggest changes for the default behavior/key accels (I think Keith
>> has some opinions on this).
>>     
>
> Yes.  I won't say that my setup, (which mostly emulates the primary 
> key bindings of KDE's Konsole), will be right for everyone, but some 
> of the defaults coming from the upstream project are badly chosen, 
> (particularly when deploying with an MSYS shell):--
>
> * ^S brings up the "settings dialogue".  NOT just an MSYS issue; it
>   interferes with XON/XOFF in anything which might use it.
>
> * ^D dumps something, IIRC, (but I can't remember exactly what);
>   interferes with MSYS EOF signalling.
>
> ...are just two examples which immediately spring to mind.
>
> FWIW, I've attached a copy of my own console.xml configuration.
>
>   
Hi,

I would not change the default key bindings. Even if they are badly 
chosen, most people do use the default settings and get used to it. 
Console2 has millions of users. I also use Console2, but not only for 
Msys. I have three tabs configured: for cmd.exe, Msys, and Cygwin. If 
you start to change short cuts, to make it Msys friendly, you forget 
that people use Console2 also for other shells. My Console2 
configuration is based on the one posted at 
http://old.nabble.com/Accepting-standard-input-from-MSYS-with-native-Win32-programs-td19432889.html 
. The posted setup configures tabs for three shells.

Erwin

Op 21-04-10 07:15, Erwin Waterlander schreef:
> Hi,
>
> I would not change the default key bindings. Even if they are badly 
> chosen, most people do use the default settings and get used to it. 
> Console2 has millions of users. I also use Console2, but not only for 
> Msys. I have three tabs configured: for cmd.exe, Msys, and Cygwin. If 
> you start to change short cuts, to make it Msys friendly, you forget 
> that people use Console2 also for other shells. My Console2 
> configuration is based on the one posted at 
> http://old.nabble.com/Accepting-standard-input-from-MSYS-with-native-Win32-programs-td19432889.html 
> . The posted setup configures tabs for three shells.
>
>   
Funny. After reading it back, I see that that was also Keith's config.
;)