Mail Archives: cygwin/2011/09/10/13:11:24
On Sat, Sep 10, 2011 at 06:10:15PM +0200, Thorsten Kampe wrote:
>* Christopher Faylor (Sat, 10 Sep 2011 09:49:50 -0400)
>> On Sat, Sep 10, 2011 at 01:44:44PM +0200, Thorsten Kampe wrote:
>> > Corinna Vinschen (Fri, 9 Sep 2011 17:09:04 +0200)
>> >> It is not at all the task of libintl to override the underlying OS,
>> >> and in the case of Cygwin, the underlying OS is Cygwin, not
>> >> Windows.
>> >
>> >Pardon me?
>> >"Cygwin is:
>> >a collection of tools which provide a Linux look and feel environment
>> >for Windows.
>> >
>> >a DLL (cygwin1.dll) which acts as a Linux API layer providing
>> >substantial Linux API functionality."
>> >
>> >Cygwin does not have any user account management, no file system, no
>> >file system permissions, etc. So when did Cygwin become an operating
>> >system in an operating system?
>>
>> Corinna, and most of the rest of us, know full well that Cygwin is not
>> a real OS but that was obviously not her point. I believe that
>> Corinna's point was that Cygwin distributed packages should not
>> normally call Windows functions.
>
>I think everyone agrees on that. The problem is that Cygwin is
>overriding the user's localization choice done in Windows. Corinna says
>users can align their shell locale with the Windows if they want to.
>Bruno says users shouldn't have to align anything but get this behaviour
>by default (and I agree).
So, stick to that point and don't quibble about a perfectly
understandable choice of words.
>>Cygwin is emulating an OS. That is a given. I assume that Corinna
>>assumed that no one would be so pedantic as to send email to hundreds
>>of people to pick nits about her use of the term "OS" in this context.
>>You really don't seem to have a point beyond being disagreeably picky.
>
>My point is that Cygwin should not override Windows. Cygwin is less
>than an OS and it's more than a simple application. Nevertheless it
>should fit in the overall Windows environment and not "contradict" it.
Even if we take your point at face value it doesn't mean that Cygwin
programs will now call Windows functions to determine their locale.
Cygwin is still the "OS" in this case and programs should not be
second-guessing it by winking and saying "I know that Windows is
underneath so I'll call a Windows function to get what I need".
It's always possible that this is a misfeature of Cygwin. If that is
the case then Cygwin can be fixed. Having a package maintainer
(inadvertently) establish new behavior by making a new package available
which introduces new behavior in programs which use it while leaving the
old behavior for programs that don't is not the way to fix it.
This hardly seems like an urgent issue given that we don't seem to have
had many complaints about the current behavior and especially given,
IIRC, this behavior was discussed at great length when it first went in.
I'd like to suggest that we revert to the previous behavior while we
discuss the best way to handle this. It's not fair to users to have the
rug pulled out from under them by unannounced changes.
>To paraphrase Corinna: "It is not the task of Cygwin to override the
>underlying OS, and in the case of Cygwin, the underlying OS is Windows,
>not Cygwin".
I doubt that Corinna said anything like that or at least not in this
context. Cygwin overrides Windows all the time. That is exactly what
it does.
>Or to quote myself: "Users who chose to have a specific language
>environment most likely want to have this choice for all their
>applications."
The bug report which started this was from a "user who chose to have a
specific language environment" but found that he couldn't do what he
wanted.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -