Re: Console codepage setting via chcp?

Re: Console codepage setting via chcp?

[Thomas Wolff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4575 bytes --]

2009/9/23 Corinna Vinschen:
> Right now, if you switch the charset via the setlocale function, you
> also switch the charset used for console output.

Andy wrote:
> That's quite a unique advantage of the Cygwin console actually,
> because it means you always get correct output even if you switch
> charset on the fly.
It might be considered an advantage but the fact that it is unique 
also means it is absolutely not portable.
In the normal Linux/Unix environment, an application that deliberately 
uses setlocale for a switch must be aware that it does NOT switch the 
terminal encoding but does this only for the purpose of specific 
invocations of wide character functions. The same applies to a 
cygwin application running in mintty, xterm, or urxvt. So in order 
to take advantage of this "advantage" the application would have 
to check the environment whether TERM=cygwin - a use case of very 
limited value, I assume.

Also, from Corinna's last statement after the discussion I had raised 
about "codepage after rlogin" or so, my assumption was that the 
setting of ${LC_ALL:-${LC_CTYPE:-$LANG}} (in shell syntax) before 
the first invocation of a cygwin application would determine the 
console encoding for the whole "cygwin session" (whatever that is, 
considering that one might invoke CMD.EXE, change LC_ALL, invoke another 
bash etc.).

Considering that a stable solution should be found, and the 
portability issue, I am not so much in favour of switching terminal 
encoding on-the-fly. esp. not as a side effect of a function that was 
not intended this way. In this sense, I also don't think this would 
be producing "correct output".


> A normal terminal, on the other hand, doesn't actually know what
> charset the app running inside it is using. Hence, for correct output,
> the user has to make sure the terminal and application charsets match,
> or use something like 'luit' to translate between them.
If I had not split off this quote, my elaboration could have been shorter...


Corinna wrote:
>ÂThis is done on the
> grounds that the console isn't capable to switch the console set by
> itself, as it is for terminal emulators like mintty. The problem with
> this approach is even documented in setup2.sgml, just commented out.
> If you use a tool like ssh to connect to a remote machine, then ssh
> uses potentially another locale and charset than the remote shell.
I don't understand this completely; I only hope that "local" and "remote" 
charset remains consistent after this problem had been fixed once, at 
least if you use a cygwin tool for the remote connection. (If you happen 
to use a Windows telnet, you will arrive remotely with the native 
Windows console codepage instead, which is acceptable in the current 
"hybrid" mode of operation as I described it in another mail.)


> ssh is always running in the "C" locale

Andy wrote:
> Are you sure? Shouldn't it be calling 'setlocale(LC_ALL, "")', thereby
> configuring the console output according to the locale variables?
The need to add setlocale to a number of tools that don't need it in 
Linux/Unix because they are simply byte-transparent was discussed before 
and deemed undesirable if I remember correctly.
I'm not sure why this should be needed now again, maybe it's related 
to the Windows file name system not being byte-transparent? If a solution 
can be found that avoids this, much trouble would be prevented, I guess.


Coming to the initial question whether the Windows console codepage 
(as affected by chcp) should be used for cygwin, I certainly vote NO;
this would be a step back behind 1.5, using the obnoxious "OEM" codepages 
by default in many cases. My vote might change to "YES" if by adding 
suitable startup conventions (like putting chcp in cygwin.bat and always 
spawning off a new Windows console to prevent changing the current CMD.EXE 
codepage... :( ), it would be assured that the default codepage would 
always be one of:
* CP1252 (like in 1.5)
* ISO 8859-1 (like in 1.7)
* UTF-8 (as discussed in another mail thread)

I guess people migrating from 1.5 could be convinced of a transition 
to UTF-8 but not of a transition to archaic CP437 or CP850, and 
teaching them to use "chcp" or "setfont" rather than the locale 
mechanism would be both cumbersome and incompatible with a Linux/Unix 
environment.


Kind regards,
Thomas

--
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

Re: Console codepage setting via chcp?

[Corinna Vinschen]

On Sep 25 14:50, Thomas Wolff wrote:
> 2009/9/23 Corinna Vinschen:
> > Right now, if you switch the charset via the setlocale function, you
> > also switch the charset used for console output.
> 
> Andy wrote:
> > That's quite a unique advantage of the Cygwin console actually,
> > because it means you always get correct output even if you switch
> > charset on the fly.
> It might be considered an advantage but the fact that it is unique 
> also means it is absolutely not portable.
> [...]

Any reason you redirected your reply to the cygwin list?  It doesn't
make much sense to disuss this in two lists and it's breaking the
threading on the cygwin-developers list for no apparent reason.

Please resend your reply to the cygwin-developers list, into the
right thread.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

mailing list responses [Re: Console codepage setting via chcp?]

[Thomas Wolff]

[meta-response, irrelevant for topic discussion]


Corinna wrote:
> Any reason you redirected your reply to the cygwin list?  It doesn't
> make much sense to disuss this in two lists and it's breaking the
> threading on the cygwin-developers list for no apparent reason.
No, sorry, I had been cross-linked to the cygwin-developers archive 
from another mail on this list so I hadn't even noticed. And once you 
are on the web archive, you wouldn't easily touch the mail with your 
normal mailer to automatic construct a proper response, especially 
since I'm not subscribe to cygwin-developers, so I was pasting the 
wrong headers :(

Another note: Since I fail to receive the cygwin mailing list in my mailbox 
for some reason, I follow that on the web archive as well. I construct 
responses manually, using the available References headers; however, 
the web archive does not quote the Message-Id of the respective message 
itself, so the response will always be positioning one behind in the thread.
I'm sorry for this, too, but I think the web archive should be fixed to 
display also the Message-Id header of each message shown, please.


> Please resend your reply to the cygwin-developers list, into the
> right thread.
I'll post an updated response after I've studied the lots of messages 
that have been added meanwhile ... :)


Kind regards,
Thomas

--
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

Re: mailing list responses [Re: Console codepage setting via chcp?]

[Corinna Vinschen]

On Sep 28 13:12, Thomas Wolff wrote:
> [meta-response, irrelevant for topic discussion]
> 
> 
> Corinna wrote:
> > Any reason you redirected your reply to the cygwin list?  It doesn't
> > make much sense to disuss this in two lists and it's breaking the
> > threading on the cygwin-developers list for no apparent reason.
> No, sorry, I had been cross-linked to the cygwin-developers archive 
> from another mail on this list so I hadn't even noticed. And once you 
> are on the web archive, you wouldn't easily touch the mail with your 
> normal mailer to automatic construct a proper response, especially 
> since I'm not subscribe to cygwin-developers, so I was pasting the 
> wrong headers :(
> 
> Another note: Since I fail to receive the cygwin mailing list in my mailbox 
> for some reason, I follow that on the web archive as well.

If you are sure you're subscribed with the correct email address,
and if you are sure that it's not something in your ISPs setup, or
your own SPAM filter, then you should send a mail to the mailing list
overseers at sourceware dot org, describing your problem.  Maybe they
can help you.

Other than that, there's also the news gateway nabble, which allows to
read the mailing list via news reader.  That's much easier than to
sift through the mailing list archive.

> I construct 
> responses manually, using the available References headers; however, 
> the web archive does not quote the Message-Id of the respective message 
> itself, so the response will always be positioning one behind in the thread.
> I'm sorry for this, too, but I think the web archive should be fixed to 
> display also the Message-Id header of each message shown, please.

Can't say anything about that.  That's how ezmlm works, I assume.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

Re: mailing list responses [Re: Console codepage setting via chcp?]

[Christopher Faylor]

On Mon, Sep 28, 2009 at 01:30:17PM +0200, Corinna Vinschen wrote:
>On Sep 28 13:12, Thomas Wolff wrote:
>> [meta-response, irrelevant for topic discussion]

That's for sure.

>> Corinna wrote:
>> > Any reason you redirected your reply to the cygwin list?  It doesn't
>> > make much sense to disuss this in two lists and it's breaking the
>> > threading on the cygwin-developers list for no apparent reason.
>> No, sorry, I had been cross-linked to the cygwin-developers archive 
>> from another mail on this list so I hadn't even noticed. And once you 
>> are on the web archive, you wouldn't easily touch the mail with your 
>> normal mailer to automatic construct a proper response, especially 
>> since I'm not subscribe to cygwin-developers, so I was pasting the 
>> wrong headers :(
>> 
>> Another note: Since I fail to receive the cygwin mailing list in my mailbox 
>> for some reason, I follow that on the web archive as well.
>
>If you are sure you're subscribed with the correct email address,

There is no one with "towo" in their name subscribed to the cygwin mailing
list.

>and if you are sure that it's not something in your ISPs setup, or
>your own SPAM filter, then you should send a mail to the mailing list
>overseers at sourceware dot org, describing your problem.  Maybe they
>can help you.

Actually, this is a *postmaster* issue.  There is no reason to bother
overseers.  See http://sourceware.org/lits.html#faq .

But, since no one with a "towo" in their email address is subscribed or
has ever subscribed there doesn't seem to be any mystery here.

Also, the web archive is not intended to be a mechanism for responding
to email.  Using it to monitor the cygwin lists is not very efficient.

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