Control auto-uppercasing of environment variables
Fri Jan 14 20:28:00 GMT 2005
Well, I suppose there are some similarities between what the uppercase_env and check_case options are used for, but check_case is specifically targeted at handling case sensitivity with regard to filenames, not environment variables. The subvalues of check_case are specified as "levels" (relaxed, adjust, and strict), so I don't think there's a clean way to use this unless we completely changed the meaning of what check_case is intended to do.
You'd also have to be able to combine subvalues - for example, some users might want strict file checking and no environment variable uppercasing, others might want relaxed file checking and uppercasing of environment variables. A separate CYGWIN option seems cleaner.
Sorry about the patch format; I'll use the unified diff format in the future.
> -----Original Message-----
> From: Igor Pechtchanski [mailto:email@example.com]
> Sent: Friday, January 14, 2005 2:52 PM
> To: Ernie Coskrey
> Cc: firstname.lastname@example.org
> Subject: Re: Control auto-uppercasing of environment variables
> On Fri, 14 Jan 2005, Ernie Coskrey wrote:
> > Cygwin automatically converts all Windows environment
> variable names to
> > uppercase. The attached patch allows users to control this
> behavior by
> > specifying an option in the CYGWIN environment variable:
> > (no)uppercase_env. The default for this option will be
> "SET", so that
> > Cygwin's default behavior is the same as always. Adding
> > "nouppercase_env" to the CYGWIN environment variable will
> cause Cygwin
> > to leave environment variable names in the same state as they are
> > defined in the Windows environment (except for PATH, which will be
> > uppercased as before).
> > My company has a product which includes a number of shell scripts.
> > We've bundled our product with a commercial product which
> provided the
> > shell functionality, and this product did not uppercase environment
> > variables. We'd like to rebase our product on Cygwin, and
> the ability
> > to turn off the auto-uppercase behavior would make this a
> much easier
> > prospect. While it would be possible to port the scripts and change
> > variable names, there are issues that make this more
> complicated than it
> > first seems. For instance, we remotely execute scripts on
> other systems
> > running our product, so during an upgrade it's possible
> that the shell
> > would be running in the old environment. Referring to uppercase
> > variable names would break in this case. Again, we could
> do something
> > to check the environmnent and use the correct version of
> the variable
> > name, but making Cygwin understand our existing scripts is a more
> > desirable solution.
> > I have briefly discussed this with Christopher Faylor, who has some
> > reservations about this functionality. His comments were:
> > =============
> > I should point out that a few people have submitted similar
> patches over
> > the years and they have been rejected. There are other
> ways to do what
> > you want to do which do not involve adding an option and
> slowing down
> > cygwin's startup. We tend to be pretty stingy when it
> comes to adding
> > new options to the CYGWIN environment variable.
> > But, if you want to discuss this, then cygwin-patches would
> be the place
> > to do so. You can quote this email there, if you want.
> > ==============
> > I can understand the reluctance to add more and more options to the
> > CYGWIN environment variable. I hope that the Cygwin community sees
> > enough value in the ability to control this aspect of
> Cygwin that this
> > modification is accepted. I don't believe that there is any real
> > performance impact with this change - at most the code
> costs a few extra
> > machine cycles, but certainly nothing noticeable.
> > Thanks for considering this modification.
> I have no comments on the functionality of the patch, but it
> seems that
> since Cygwin already parses $CYGWIN for the check_case
> option, adding your
> option as a suboption of check_case instead of a brand new
> option might be
> the way to go, especially since the intent is similar.
> There's still the
> overhead of checking the setting, but that might be less of
> an obstacle
> than adding a new $CYGWIN top-level option.
> Also, it might be easier to review if you sent the patch in Unidiff
> format, rather than the context diff (use "diff -up" instead of "diff
> |\ _,,,---,,_ email@example.com
> ZZZzz /,`.-'`' -. ;-;;,_ firstname.lastname@example.org
> |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
> '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
> "The Sun will pass between the Earth and the Moon tonight for a total
> Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
More information about the Cygwin-patches