Mail Archives: cygwin-developers/1998/10/13/06:53:04

From: lhall AT rfk DOT com (Larry Hall)
Subject: Re: color problem when not using bash
13 Oct 1998 06:53:04 -0700 :
Message-ID: <>
References: <361FC4AE DOT 47DE7285 AT cityweb DOT de>
Mime-Version: 1.0
To: Corinna Vinschen <corinna DOT vinschen AT cityweb DOT de>,
cygwin32-developers AT cygnus DOT com

At 10:33 PM 10/10/98 +0200, Corinna Vinschen wrote:
>Hallo Larry,
>Larry Hall wrote:
>> You're right.  There is an issue here, although it does not seem to be
>> limited to tcsh.  What I found was if I followed what you suggested
>> (below), I could get similar behavior (even without changing my settings
>> for CYGWIN32.)  One thing you didn't say in your description was whether
>> you specified the new color for only the current window or for all windows
>> with the same title and whether you tried all these tests in the same
>> window you set the colors in or in a new one.  Assuming that you were
>I have changed the colors once in the Console control dialog and I start
>my shells from Windows links in the start menu. They have their own
>color settings, but mine are identical to my standard settings. I prefer
>black on light grey. I have the effect in this case, I have _never_
>changed the colors in one of the currently opened window.

Sounds similar, although not exactly the same, as the way I make my settings
and use them.

>> working in the same window as the one you set the colors in, I found your
>> tests reproducible.  However, if I set the colors in one window, saved
>> them for all windows with that title, and then started a new window with
>> that title, I could not reproduce your problem.  Also, while I found bash
>> to be a little better behaved, I found that setting the colors in a window
>> and then going back to "Properties" to try to set the colors again caused
>> a crash in bash.  I don't know if you would see the same thing or not.  I
>I have found, that going back to properties, crashes in tcsh, too.
>I have tested it in b19.2, in my b19.4 with tape support and in b20a1.
>It's persistent _and_ it's in mode CYGWIN32="... tty ..." too!
>Seems to be a cruel problem in cygwin32. 

Yes, just one of at least a few!;-)

>> think it would be worthwhile though for you to try your same tests after
>> you've changed colors in one window and then exited and started another.
>> I think there is a bug in bash or cygwin which is corrupting memory when
>> the background (or maybe foreground color too) is changed in the "Properties"
>I have tried it, and found, that the crash also happens, if the
>only action in the properties dialog is pressing "Cancel"!!!
>And there's a possible difference: I start the shells without the
>roundabout of a '.bat' file! My links are direct links:
>bash.lnk = link to f:\bin\bash.exe -login
>tcsh.lnk = link to f:\bin\tcsh.exe -l
>The rest is done in /etc/profile resp. /etc/csh.login.
>And if you start the shells from a previous started cmd,
>the properties dialog runs without any problem!
>But starting the shell with cmd or directly, the color
>problem remains the same with newer winsup.

I don't start bash from a link or a bat file.  I start it directly (bash 
-login).  I have all my environment variables where they belong, in the 
environment!;-)  Things that are more specific to cygwin or "need" to be
reset for cygwin I do in my /etc/profile too.  I see the same things you do.
 I can't bring up the "Properties" box twice in the DOS box bash "starts".  
I can bring up the "Properties" more than once in a cmd.exe that I started 
bash in manually.  This seems to be consistent and significant...

>> but I haven't narrowed it down further than this so far.
>> Larry
>Do you suppose, the problem is a memory violation in some part
>of cygwin and different code lengths or some else will
>produce different, but reproducable bad results?

Memory corruptions tend to move around once you start investigating them
(i.e. recompiling the code so that you can debug them.)  They also tend 
to move around and change if any change is made to the code or, more 
correctly, to the final location of problem area in the compiled code.
Given some of your input, I guess I'm leaning toward the diagnoses which
suggests that this is now more of a strict logic problem when bash 
interacts with the properties of the DOS box in the case where bash is 
run automatically with cmd.exe.  The fact that both you and I see the 
problem on multiple different versions of cygwin points me more
in this direction than in my original assertion of a memory corruption.

Larry Hall                              lhall AT rfk DOT com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797     

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019