From: "YO4 (Yoshinao Muramatsu) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "YO4 (Yoshinao Muramatsu)" <noreply@ruby-lang.org>
Subject: [ruby-core:120276] [Ruby master Misc#20774] Remove remaining locale dependent code from Windows port
Date: Tue, 17 Dec 2024 12:19:22 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-111043.20241217121922.5550@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-20774.20241001095721.5550@ruby-lang.org>
Issue #20774 has been updated by YO4 (Yoshinao Muramatsu).
[github PR#11799](https://github.com/ruby/ruby/pull/11799/commits) currently has two patches:
* Windows: Change command line interface to UTF-8
* Windows: Use Unicode aware function to retrieve console inputs
Could the former be split and merged?
The latter is no longer a must, as console input in codepage 65001(UTF-8) works as intended in the latest Windows Terminal.
Of course, it remains important for environments where Windows Terminal is not available, including Windows Server 2019, or for when the Command Prompt Window are used.
Differences in behavior due to codepage settings and console selections should be minimized as they confuse the novice.
----------------------------------------
Misc #20774: Remove remaining locale dependent code from Windows port
https://bugs.ruby-lang.org/issues/20774#change-111043
* Author: larskanis (Lars Kanis)
* Status: Open
----------------------------------------
The external_encoding of files, file names and ENV on Windows were changed from locale codepage to UTF-8 in ruby-3.0.
But there are still several remaining points where locale encoding is used although there is no need to do so.
The Windows port is already fully UTF-16/UTF-8 based and locale encoding is only used for historical and not for technical reasons.
My proposal is to remove (most of) the locale dependent conversions from the ruby code for Windows.
Before I open pull requests in this regard, I would like to confirm this direction with the ruby core team.
Let me show what I mean:
```
# täst-locale-enc.rb
def pr(*strs)
strs.each do |str|
p [str, IO===str ? str.external_encoding&.name : str.encoding.name]
end
end
if $0==__FILE__
pr STDIN # => [#<IO:<STDIN>>, "CP850"]
pr $0 # => ["ruby/t\x84st-locale-enc.rb", "CP850"]
pr __FILE__ # => ["ruby/t\x84st-locale-enc.rb", "CP850"]
pr __dir__ # => ["C:/Users/kanis/ruby", "CP850"]
pr 'ä' # => ["ä", "UTF-8"]
pr '€' # => ["€", "UTF-8"]
pr $:.first # => ["C:/Users/kanis/t\xE2\x82\xACst", "ASCII-8BIT"]
pr $:.last # => ["C:/Ruby33-x64/lib/ruby/3.3.0/x64-mingw-ucrt", "CP850"]
require "win32/registry"
pr Win32::Registry::HKEY_CURRENT_USER.open("Environment")['TMP']
# => ["C:\\Users\\kanis\\AppData\\Local\\Temp", "UTF-8"]
pr Win32::Registry::HKEY_CURRENT_USER.open("\\").each_key{ break _1 }
# => ["AppEvents", "CP850"]
end
# execute with: ruby -It€st ruby\täst-locale-enc.rb
```
I wrote the results on `ruby-3.3 x64-mingw-ucrt` right into the code.
The situation is even worse when called with `-e` script:
```
$ ruby -It€st -r .\ruby\täst-locale-enc.rb -e "pr STDIN, $0, __FILE__, __dir__, 'ä', '€', $:.first, $:.last"
[#<IO:<STDIN>>, "CP850"]
["-e", "CP850"]
["-e", "UTF-8"]
[".", "US-ASCII"]
["\x84", "CP850"]
["?", "CP850"]
["C:/Users/kanis/t\xE2\x82\xACst", "ASCII-8BIT"]
["C:/Ruby33-x64/lib/ruby/3.3.0/x64-mingw-ucrt", "CP850"]
```
There are also some inconsistencies like that it's possible to `require` script names with characters outside of the codepage, but it fails to execute a script directly or by using `require_relative` :
```
$ ruby -r .\t€st-locale-enc.rb -e "pr STDIN"
[#<IO:<STDIN>>, "CP850"]
$ ruby .\t€st-locale-enc.rb
ruby: Invalid argument -- ./t?st-locale-enc.rb (LoadError)
```
Maybe there are more places which are working with locale codepage - these are only the few that I remember from memory.
I would like to change all the above results to be UTF-8 encoded, like it is the case on Ubuntu.
Compatibility
-------------
Changing the encoding of returned strings is of course an API change.
IMHO it is still something we should change in a minor release of ruby.
The reason is that I don't remember about only a single issue cased by the change to UTF-8 in ruby-3.0 in the company I work for.
To the contrary many issues are caused by using locale codepage where some non-ASCII characters work and other characters don't.
Most issue with ruby-3.0 were cased by the keyword argument changes.
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/
next prev parent reply other threads:[~2024-12-17 12:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-01 9:57 [ruby-core:119380] " larskanis (Lars Kanis) via ruby-core
2024-10-04 15:43 ` [ruby-core:119456] " larskanis (Lars Kanis) via ruby-core
2024-12-17 12:19 ` YO4 (Yoshinao Muramatsu) via ruby-core [this message]
2024-12-17 21:13 ` [ruby-core:120282] " larskanis (Lars Kanis) via ruby-core
2024-12-18 8:07 ` [ruby-core:120295] " larskanis (Lars Kanis) via ruby-core
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-111043.20241217121922.5550@ruby-lang.org \
--to=ruby-core@ml.ruby-lang.org \
--cc=noreply@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).