This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Console codepage setting via chcp?


2009/9/25 Corinna Vinschen:
>> The important thing is that file names, user names, and env variables
>> are represented by the same byte sequences throughout the life of a
>> program. Determining their translation at program startup ensures
>> that.
>
> But that's not the only important point.  If two applications having
> different locales talk to each other, they have different ideas of the
> filenames.  Even their CWD could look different, even though it's
> actually the same.

True. However, the environment locale setting is constant throughout a
process tree unless the user explicitly changes it.

This is different from the issue with filenames depending on whether
setlocale is called, because that's outside the user's control.


> The problem is that some of these strings are fetch only once, when
> the first Cygwin process starts.  The user name, for instance, which is
> inherited by child processes.  The CWD is also typically only fetched
> once, when the first process starts up or when a process calls chdir.
> Then it's inherited by child processes as is.

Would it be possible to fetch them at every process startup instead?


>> Now, if an application calls setlocale with a charset other than
>> what's set in the environment and it interprets the byte sequences
>> according to that charset, then that's its own responsibility. This
>> would go awry on Linux too, e.g. if a system is set up with
>> LANG=en.ISO-8859-1, apps shouldn't try to display filenames as UTF-8.
>
> Yeah, but it's only a problem displaying data on the screen.  How bad is
> that?

I think we're agreed on that point.


> it seems to me that the best approach is to stick to one
> single representation of system object names throughout the lifetime
> of a process tree.

This would make it futile to have the locale and charset settings in
mintty 0.5's options dialog, which provide a simple user interface to
Cygwin's locale system (and which took quite a bit of work to get
right, although of course that's irrelevant).

Since mintty is itself a Cygwin process, the filename encoding would
already be fixed before mintty gets a say about it, hence people would
either need to invoke it through a batch script, or set the locale
variables somewhere in the system properties, neither of which is
intuitive.

Furthermore, this approach would remove other uses of program-specific
locale settings, e.g. specifying a charset for file archiving
operations as in the tar example I'd given, or dealing with non-UTF-8
programs.

Please reconsider. I'm sorry for raising these issues at such a late
stage, and I wish I'd understood locales sooner.

Andy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]