パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Bash 3.0 リリース」記事へのコメント

  • known bug (スコア:3, 参考になる)

    by Anonymous Coward on 2004年07月30日 11時24分 (#598258)
    プロンプト (PS1 など) において、文字幅の計算にバイト数を使ってしまっています。

    このため、UTF-8 ロケールでプロンプトにロシア文字や漢字などを設定すると、 行の折り返しがおかしくなります。 いま、Debian unstable (Sid) の bash 3.0-1 を使ってみましたが、 なおっていません。 すでに1年以上も放置されているバグ [debian.org]らしいです。

    EUC-JP ロケールでは、(ASCII と JIS X 0208 に限れば) 文字幅とバイト数が一致するので、この問題は起こりません。

    ちなみに、Debian において、debconf を readline インタフェースで ja_JP.UTF-8 ロケールで使うと画面がおかしくなるのは、これが原因です。

    • Re:known bug (スコア:1, 興味深い)

      by Anonymous Coward on 2004年07月30日 12時31分 (#598295)
      国際化に伴うバグ情報ってどうにか整理できないんですかね。
      なんか毎度毎度同じようなバグがあっちこっちのアプリで出てくる現状は
      ものすごく無駄な感じがしてしょうがないんですけど。

      Unicode の中の人は死力を尽くして啓蒙活動する義務があるんじゃないか?
      親コメント
      • Re:known bug (スコア:1, おもしろおかしい)

        by Anonymous Coward on 2004年07月30日 12時39分 (#598302)
        > Unicode の中の人は死力を尽くして啓蒙活動する義務があるんじゃないか?

          ナイ。マッタクナイ。
        どうして、ここで Unicode ダケが問題にされてるのか分からん。

        日本語を使えるようにすることによるバグ情報ってどうにか整理できないんですかね。
        なんか毎度毎度同じようなバグがあっちこっちのアプリで出てくる現状は
        ものすごく無駄な感じがしてしょうがないんですけど。

        日本人は死力を尽くして啓蒙活動する義務があるんじゃないか?
        親コメント
        • by Anonymous Coward
          つーか、shellで日本語なんか使うなよ...
          • by grooveline (23428) on 2004年07月30日 13時25分 (#598337)
            つーか、shellで日本語なんか使うなよ...
            同意。けど、Sambaでファイル共有していると日本語ばっかだし、使うと便利な環境は多いよね。

            仕方ないので「project_ほげほげ」とかにして、「$ cd project*」や「$ cd p(tab-key)」で対応。それなりに使えますよ。周りも真似してくれるのは良いのだけど、半角にしている目的を知らない奴は全角で「project_ほげ」にしちゃうんだよな・・・。

            vi使える人には「set -o vi」を教えてあげよう。案外知らない人が多いっす。

            親コメント
            • by s-tomo (2841) on 2004年07月30日 18時03分 (#598486) ホームページ 日記
              $ pwd
              /home/s-tomo/projects
              $ ls
              project_????????/ project_????????/
              $ echo *
              project_ふがふが project_ほげほげ
              $ cd project*
              $ pwd
              /home/s-tomo/projects/project_ふがふが

              「ほげほげ」の方を指定するにはどうすれば.........
              親コメント
            • by Anonymous Coward
              Sambaとは直接関係ないかもしれないですけど、GNU/LinuxからNTFSを
              マウントする際は、iocharset=euc-jpってオプションを指定しておく
              と日本語のファイル名も問題無く表示できますよ。ファイル名の補完
              も出来ます。
          • by Anonymous Coward on 2004年07月30日 13時27分 (#598340)
            これ [srad.jp]をみて「なるほど必要だな」と思いました。
            親コメント
          • Re:known bug (スコア:0, 余計なもの)

            by Anonymous Coward
            > つーか、shellで日本語なんか使うなよ...

            あんたの好みを押しつけられても困る

            つーか、コンピュータで日本語なんか使うなよ...
        • by Anonymous Coward
          >どうして、ここで Unicode ダケが問題にされてるのか分からん。

          アホですか?
          JIS X0208 では問題が起こらないからでしょ。
          • Re:known bug (スコア:2, 興味深い)

            by masaru (2119) on 2004年07月30日 20時28分 (#598528) ホームページ

             バイト数 == Half width の数 な関係ならば問題ないのだろうけど、 EUC-JP の JISX0201とか 3byte の部分とかならば問題出るとかそういう話なら、「Unicodeダケの問題」とはいえないのでしょう。  イロイロな意味で バイト数 != 文字列の幅 っていうことを言っていかないと。

            親コメント
            • by Anonymous Coward
              仰るとおりですね。
              これに文字数も含めて『バイト数と文字数と文字列の幅は一致すると考えちゃいかん!』と掲げれば,#598295 [srad.jp]のACの方が言ってた『なんか毎度毎度同じようなバグがあっちこっちのアプリで出てくる現状』もかなり改善できるでしょう。
              国際化プログラミングする上での心得ですので,
          • by j3259 (7093) on 2004年07月31日 5時17分 (#598663) ホームページ 日記
            > アホですか?
            > 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などなど。

            二バイト系を毎日使ってる日本人でさえこのへんを良く分かってない人が多いわけで。「アホですか?」とか言ってるし。

            参考リンク

            親コメント
          • by Anonymous Coward
            > JIS X0208 では問題が起こらないからでしょ。

              encoding 方式が書いてないんだけど、SJISだと \(0x5c) で問題あるよ。
            あ、上のほうで EUC-JP って言ってたっけ? JISX0201 はどうするの?
            あぁ、JIS roman/kana は使うなって?じゃぁ、JISX0212 は?

              日本語以外で言うなら、 EUC-TW とかどうすんの? EUCから逸脱してるから外す?
            BIG5 も 0x5c 二バイト目に入るね。どうすんの? GBKは? GB18030は?

             
        • by Anonymous Coward
          >どうして、ここで Unicode ダケが問題にされてるのか分からん。

          問題っていうか、未来は Unicode の中にあるってことになってるし、
          実際多くのOS/アプリがそっち向かっている中で、同じような問題があちこち
          で起きているからじゃないの?

          # 「日本語」の話を持ち出す方がよほど奇異に見えるが
          • by Anonymous Coward
            元コメントの

            >>国際化に伴うバグ情報ってどうにか整理できないんですかね。
              から
            >>Unicode の中の人は死力を尽くして啓蒙活動する義務があるんじゃないか?
             
            国際化の話をしてるのになんで Unicode の中の人だけが死力を尽くす必要がある?ないでしょ?

            > # 「日本語」の話を持ち出す方がよほど奇異に見
    • by Henrich (121) on 2004年07月30日 13時06分 (#598320)
      おぉ、すごく参考になります。ありがとう。
      debconf の ja.po を UTF-8 にしないのか?とmaintainerから突っ込まれていたので、
      それに対する返事の参考にします。やっぱり問題あるんですね。

      ありがとう、ありがとう、ありがとう。
      親コメント
      • Re:known bug (スコア:2, 参考になる)

        by Anonymous Coward on 2004年07月30日 14時02分 (#598351)
        poファイルのエンコーディングと、利用環境のエンコーディング (たとえば ja_JP.UTF-8 で debconf を使う) は関係ないですよ。たとえ po ファイルが UTF-8 で書かれていても、ja_JP.EUC-JP 環境で利用可能です。

        まあ、ja.po ファイルを UTF-8 で書くと、EUC-JP に変換不可能な文字が紛れ込んでしまい、EUC-JP 環境では文字化けするという可能性が生じますけど。

        ついでに言えば、UTF-8 ←→ EUC-JP 変換テーブルがシステムというかベンダーごとに異なるので、たとえば Windows 用の UTF-8 対応エディタで ja.po を編集すると、EUC-JP (というか JIS X 0208) の範囲に入っている文字を使った場合でさえ、Linux 上で文字化けするなんてことが起こりえますが。たとえば「~」とか「-」とか。そういう面倒にかかわり合いたくなければ、po ファイルを EUC-JP で書くことをおすすめします。

        親コメント
        • by Anonymous Coward
          てことはUTF-8を使えるようにすることはあっても
          EUC-JPを置換するものにはなりえないということ?

          俺的にはEUC-JPの世界でのんきに暮らしたいのだが
          WindowsとかGNOMEとかUTF-8が攻めて(?)きて
          またーり出来んのだが。
          • by Jadawin (2174) on 2004年07月30日 14時47分 (#598385) 日記
            少しずつ移行しようとするとはまるってことでしょう。
            UTF-8にしたければ、すべてを一斉にUTF-8にしないと不都合がでる。それを
            Unicodeの欠点とみなすかどうかは、立場の違い。

            #私の場合、未だにmltermとか、mozilla、emacsを立ち上げる時だけ、
            #ja_JP.eucJPに設定して、それ以外はすべてCロケールですが。やっぱり、
            #いずれenロケールに移行しないといけないのだろうか。
            親コメント
            • by Anonymous Coward
              > #ja_JP.eucJPに設定して、それ以外はすべてCロケールですが。やっぱり、
              > #いずれenロケールに移行しないといけないのだろうか。

              そうなの? C は廃止で en に移行する流れなの?
              • by Anonymous Coward
                > そうなの? C は廃止で en に移行する流れなの?

                ISO Cのlocaleの仕組みからして廃止はありえないし、またする必要もない。けど、UTF-8を取り扱おうとするならen_US.UTF-8とかen_GB.UTF-8といったlocaleが必要になる。
              • by Anonymous Coward
                C localeは「英語」localeじゃないってこった。
              • by masaru (2119) on 2004年07月31日 1時24分 (#598610) ホームページ
                C言語のコンパイラに依存、とかいう曖昧な locale ですねー。
                親コメント
              • by Anonymous Coward
                > C言語のコンパイラに依存、とかいう曖昧な locale ですねー。

                C locale の由来はそうなの? 詳しく教えてほしいんだけど、
                「コンパイラに依存」ってどういう意味?

                できればポインタを教えてください。
              • by Anonymous Coward
                > C言語のコンパイラに依存、とかいう曖昧な locale ですねー。

                んー,そんなに曖昧でもないんじゃないですか。
                Single UNIX Specification [opengroup.org] を見ると,結構かっちり決まっていると思います。
    • Re:known bug (スコア:1, 興味深い)

      by Anonymous Coward on 2004年07月30日 14時04分 (#598353)
      文字幅を計算する為のライブラリとかってありますか?
      親コメント
    • by Anonymous Coward
      >このため、UTF-8 ロケールでプロンプトにロシア文字や漢字などを設定すると、行の折り返しがおかしくなります。

      貴殿にこのやっつけパッチを進呈しよう。

      --- bash-3.0/lib/readline/display.c.org 2004-05-28 11:57:51.000000000 +0900
      +++ bash-3.0/lib/readline/display.c 2004-07-30 22:51:06.392651768 +0900
      @@ -342,6 +342,7 @@
                        &prompt_invis_chars_first_line,
                        &prompt_physical_chars);
      • 上の簡易パッチがあっさりスルーされて悔しいので
        もう少しきちんと仕上げてみました。暇で親切な人は
        検証してみてよさそうなら、本家に送って欲しい。
        私は英語だめなんでね。

        --- bash-3.0/lib/readline/display.c.org 2004-05-28 11:57:51.000000000 +0900
        +++ bash-3.0/lib/readline/display.c 2004-08-01 14:05:23.807209824 +0900
        @@ -253,6 +253,9 @@
                              else
                          ninvis += ind - pind;
        • 紹介してみました [debian.org]。ただし Debian の bash メンテナに対してですが。

          こんな英語でいいのかな

          親コメント
        • ためしてみました。うまくいっているようです。ただし、プロンプト自身が80カラムを超える場合はだめなようです。
          • まだ見ている人いるかな。

            >ためしてみました。うまくいっているようです。ただし、プロンプト自身が80カラムを超える場合はだめなようです。
            一応対処してみましたが、手抜きで無駄に効率が悪いし、ソースを読みきれてないので副作用があるかも。
            パッチのままだと書き込めないので、見れば分かるけど、BASE64でエンコードしてます。

            begin-base64 644 rl2.patch.gz
            H4sICJ/PD0EAA3JsMi5wYXRjaAB9VMtu2zAQPEdfMUc7shzJjeNX4rhtWrQF
            mntRFAItURYRiRQoOopR5N+71MNPoDzYIrkzOzu7kud5iEVZZGw3jIZKb65G
            vn/r+WNvNEUQzMeT+TgY+t2C689833Fd94BqEVPPv4U/mge38/Hd8G4y
            • 上のふたつのパッチを合わせてブラッシュアップした最終バージョンです。

              begin-base64 644 rl_utf8.patch.gz
              H4sICLGlEEEAA3JsX3V0ZjgucGF0Y2gAlVVNb9NAED07v2JQL0lsJ3ZSpzSm
              kBaKQIKe4IAQsvyxjlddey170xAQ/52Z3TjkAwrsIbbXO2/evHkTu64LSdwW
              7nTkjQVPxg2LM8ErNs54W4t4M0pHsllaE887d73AnTwF358HF/PAH3ndAtu7
              9Lyebdt/w9riPHW9c/ARJJh7/mga+LPpLPAnW5zFAtzJ+aVzATZdfA8Wix5Y
              oNe64IJBX7juYLcHMGww9xUMa9sOd9s8h/4Tvqxkw6vloOdaViPAvgJeZeBC
              jZewZ1vWd/oB+O07gLrYtGkRNy29jRoRpVJEa56pol+XytFHHQob6IAfu+xM
              tAwfrIpXD7w9xu5O1a4bWpY1HkIqy5pVbawY5LIBgTcNhq
              • 上のパッチには無限ループに入るバグがありました。こちらが訂正したものです。

                begin-base64 644 rl_utf8-2.patch.gz
                H4sIAP7vEEEAA5VVTXObSBA9o1/RqVxAgIQ+sC0RO3ISp5KqxKfkkNraovgY
                xJSBoQBZUVL+7+meESxCG2d3DgJ6pl93v349sm0bwqBO7cXEmWY8nFYsiDNe
                sGnM6zILDpNoIqqtNnecpe249vwKZrO1e7l2ZxOnXWA6K8cZmab5J6wjzpXt
                LGG+WDtXa/dislwtlu7SRZPC2WzAni9X1iWY9Jg5sNmMQAO59inPGOiZbRud
                DWBcYexrGJem6XVmnoD+gm8LUfFia4xsTasyMK+BFzHYUOLDG5ma9pN+AP51
                D6BMD3WUBlVNu36V+ZHI/D2Pm1Qv88aSRy1yM6TDUxedZTXDD63gxSOvh9jt
                qdK2PU3TpmOIRF6yog4aBomoIMOXCl2iiuWsaG

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

処理中...