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. Ernie > -----Original Message----- > From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] > Sent: Friday, January 14, 2005 2:52 PM > To: Ernie Coskrey > Cc: cygwin-patches@cygwin.com > 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. > > Ernie, > > 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 > -c"). > Igor > -- > http://cs.nyu.edu/~pechtcha/ > |\ _,,,---,,_ [EMAIL PROTECTED] > ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] > |,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 >
