アカウント名:
パスワード:
このため、UTF-8 ロケールでプロンプトにロシア文字や漢字などを設定すると、 行の折り返しがおかしくなります。 いま、Debian unstable (Sid) の bash 3.0-1 を使ってみましたが、 なおっていません。 すでに1年以上も放置されているバグ [debian.org]らしいです。
EUC-JP ロケールでは、(ASCII と
つーか、shellで日本語なんか使うなよ...
仕方ないので「project_ほげほげ」とかにして、「$ cd project*」や「$ cd p(tab-key)」で対応。それなりに使えますよ。周りも真似してくれるのは良いのだけど、半角にしている目的を知らない奴は全角で「project_ほげ」にしちゃうんだよな・・・。
vi使える人には「set -o vi」を教えてあげよう。案外知らない人が多いっす。
バイト数 == Half width の数 な関係ならば問題ないのだろうけど、 EUC-JP の JISX0201とか 3byte の部分とかならば問題出るとかそういう話なら、「Unicodeダケの問題」とはいえないのでしょう。 イロイロな意味で バイト数 != 文字列の幅 っていうことを言っていかないと。
問題になってるのは、ビット表現の話みたいなので、 関係してくるのは文字コード、正確には文字エンコーディング法(character encoding)でしょう。 JIS X 0208 の文字でも、Shift JIS、ISO-2022-JP、EUC-JP などの方法で表現できます。 Unicode でも、UTF-8、UTF-16、UTF-16BE、UTF-16LEなどなど。
二バイト系を毎日使ってる日本人でさえこのへんを良く分かってない人が多いわけで。「アホですか?」とか言ってるし。
参考リンク
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
known bug (スコア:3, 参考になる)
このため、UTF-8 ロケールでプロンプトにロシア文字や漢字などを設定すると、 行の折り返しがおかしくなります。 いま、Debian unstable (Sid) の bash 3.0-1 を使ってみましたが、 なおっていません。 すでに1年以上も放置されているバグ [debian.org]らしいです。
EUC-JP ロケールでは、(ASCII と
Re:known bug (スコア:1, 興味深い)
なんか毎度毎度同じようなバグがあっちこっちのアプリで出てくる現状は
ものすごく無駄な感じがしてしょうがないんですけど。
Unicode の中の人は死力を尽くして啓蒙活動する義務があるんじゃないか?
Re:known bug (スコア:1, おもしろおかしい)
ナイ。マッタクナイ。
どうして、ここで Unicode ダケが問題にされてるのか分からん。
日本語を使えるようにすることによるバグ情報ってどうにか整理できないんですかね。
なんか毎度毎度同じようなバグがあっちこっちのアプリで出てくる現状は
ものすごく無駄な感じがしてしょうがないんですけど。
日本人は死力を尽くして啓蒙活動する義務があるんじゃないか?
Re:known bug (スコア:0)
Re:known bug (スコア:1)
仕方ないので「project_ほげほげ」とかにして、「$ cd project*」や「$ cd p(tab-key)」で対応。それなりに使えますよ。周りも真似してくれるのは良いのだけど、半角にしている目的を知らない奴は全角で「project_ほげ」にしちゃうんだよな・・・。
vi使える人には「set -o vi」を教えてあげよう。案外知らない人が多いっす。
Re:known bug (スコア:1)
/home/s-tomo/projects
$ ls
project_????????/ project_????????/
$ echo *
project_ふがふが project_ほげほげ
$ cd project*
$ pwd
/home/s-tomo/projects/project_ふがふが
「ほげほげ」の方を指定するにはどうすれば.........
Re:known bug (スコア:2, 参考になる)
2370528 project_ふがふが
2370525 project_ほげほげ
> cd `find . -inum 2370528`
Re:known bug (スコア:1)
project_???????????? project_????????????
$ echo *
project_ふがふが project_ほげほげ
$ cd `echo * | awk '{ print $1 }'`
$ pwd
/home/ueyama/hoge/project_ふがふが
# UNIX系OSなら、色々なパターンがありそう。
Re:known bug (スコア:1)
Re:known bug (スコア:0)
マウントする際は、iocharset=euc-jpってオプションを指定しておく
と日本語のファイル名も問題無く表示できますよ。ファイル名の補完
も出来ます。
以前は私もそう思いましたが (スコア:1, おもしろおかしい)
Re:known bug (スコア:0, 余計なもの)
あんたの好みを押しつけられても困る
つーか、コンピュータで日本語なんか使うなよ...
Re:known bug (スコア:1)
#使ったことない(笑)けどIDで
Re:known bug (スコア:0)
アホですか?
JIS X0208 では問題が起こらないからでしょ。
Re:known bug (スコア:2, 興味深い)
バイト数 == Half width の数 な関係ならば問題ないのだろうけど、 EUC-JP の JISX0201とか 3byte の部分とかならば問題出るとかそういう話なら、「Unicodeダケの問題」とはいえないのでしょう。 イロイロな意味で バイト数 != 文字列の幅 っていうことを言っていかないと。
Re:known bug (スコア:0)
これに文字数も含めて『バイト数と文字数と文字列の幅は一致すると考えちゃいかん!』と掲げれば,#598295 [srad.jp]のACの方が言ってた『なんか毎度毎度同じようなバグがあっちこっちのアプリで出てくる現状』もかなり改善できるでしょう。
国際化プログラミングする上での心得ですので,
JIS X0208 (スコア:1)
> JIS X0208 では問題が起こらないからでしょ。
JIS X 0208 は文字セット(character set)で、文字の一つひとつに値は与えられていますが、最終的なビット表現は規定しません。Unicode も同様。
問題になってるのは、ビット表現の話みたいなので、 関係してくるのは文字コード、正確には文字エンコーディング法(character encoding)でしょう。 JIS X 0208 の文字でも、Shift JIS、ISO-2022-JP、EUC-JP などの方法で表現できます。
Unicode でも、UTF-8、UTF-16、UTF-16BE、UTF-16LEなどなど。
二バイト系を毎日使ってる日本人でさえこのへんを良く分かってない人が多いわけで。「アホですか?」とか言ってるし。
参考リンク
Re:known bug (スコア:0)
encoding 方式が書いてないんだけど、SJISだと \(0x5c) で問題あるよ。
あ、上のほうで EUC-JP って言ってたっけ? JISX0201 はどうするの?
あぁ、JIS roman/kana は使うなって?じゃぁ、JISX0212 は?
日本語以外で言うなら、 EUC-TW とかどうすんの? EUCから逸脱してるから外す?
BIG5 も 0x5c 二バイト目に入るね。どうすんの? GBKは? GB18030は?
Re:known bug (スコア:0)
問題っていうか、未来は Unicode の中にあるってことになってるし、
実際多くのOS/アプリがそっち向かっている中で、同じような問題があちこち
で起きているからじゃないの?
# 「日本語」の話を持ち出す方がよほど奇異に見えるが
Re:known bug (スコア:0)
>>国際化に伴うバグ情報ってどうにか整理できないんですかね。
から
>>Unicode の中の人は死力を尽くして啓蒙活動する義務があるんじゃないか?
国際化の話をしてるのになんで Unicode の中の人だけが死力を尽くす必要がある?ないでしょ?
> # 「日本語」の話を持ち出す方がよほど奇異に見