Masakazu Takahashi
emasa****@gmail*****
2011年 10月 18日 (火) 21:51:28 JST
Fork元木さんと長南さんのご指摘について、まとめてリプライします。
元木さん:
> 訳のチェックの方ですが、READLINE 以降を読んでいます。
長期となると思いますので、無理のない範囲で、よろしくお願いします。
READLINE のセクションは多くが readline(3) と共通なので、
そちらにも応用できるかもしれません。
元木さん:
>> >>>> .B BASH_CMDS
>> >>>> .\"O An associative array variable whose members correspond to the internal
>> >>>> .\"O hash table of commands as maintained by the \fBhash\fP builtin.
>> >>>> .\"O Elements added to this array appear in the hash table; unsetting array
>> >>>> .\"O elements cause commands to be removed from the hash table.
>> >>>> 組み込みコマンド \fBhash\fP で扱うコマンドの内部的なハッシュテーブルに
>> >>>> 対応する連想配列変数です。
>> >>>> この配列に要素を追加すると、ハッシュテーブルにも追加されます。
>> >>>> 配列から要素を削除すると、ハッシュテーブルから削除されます。
>
> [...]
>
>> > maintain に「操作」ではなく「管理」を選んだのも、三行目と四行目以下を
>> > 区別しようという気持ちが働いたからです。もともと maintain という言葉は
>> > 「操作」より「管理」に近いでしょうし。
>>
>> 私の語感では、「管理」というと manage というか保持しているイメージで
>> （喩えるとアパートの管理人）、maintain というのはそこに修繕などの行為を
>> するイメージです（喩えるとアパートの内装工事をする人）。そういう意味で
>> 「操作」という言葉を使いました。
>
> WEBSTAR's の英英辞典によると、maintain は
> to keep in existence; preserve
> to keep in a certain condition or state
> となっています。「きちんとした状態に保つ」というニュアンスで、
> 「維持管理」が近いと思います。修繕するといった行為は、「きちんとした状態に保つ」
> ための手段になるのではないでしょうか。
>
> 訳に戻ると、
> bash 自身が、bash が認識するコマンド群がハッシュテーブルに登録された状態に
> 保つという意味で「管理」を使うのが自然だと思っています。
> 少し微妙な点としては、組み込みコマンド hash が maintain するという部分で、
> hash コマンドはハッシュテーブルを「操作」するためのもので、hash コマンドを
> 呼び出してハッシュテーブルを「管理」するのは bash 自身という点です。
はい、元木さんが最後に書かれているように私は解釈しており、前のメールで
書いた比喩はそれを指したものです。
元木さん:
>> >>>> .B BASH_COMMAND
>> >>>> .\"O The command currently being executed or about to be executed, unless the
>> >>>> .\"O shell is executing a command as the result of a trap,
>> >>>> .\"O in which case it is the command executing at the time of the trap.
>> >>>> 現在実行しているか実行しようとしているコマンドです。
>> >>>> ただし、トラップによりコマンドを実行しているときのコマンドは除きます。
>> >>>
>> >>> 「ただし」以下は、「ただし、トラップによって実行されるコマンドは
>> >>> 除きます」で十分では。あるいは、原文どおり「ただし、トラップの結果
>> >>> として、シェルが実行しているコマンドは除きます」か。
>> >>>
>> >>> それから、「in which case it is the command executing at the time of
>> >>> the trap」の訳が抜けています。
>> >>
>> >> 前者の指摘で削っている部分が後者の指摘の部分かと思います。
>> >
>> > 素直に訳してみます (実際の動作の確認はしていません)。
>> >
>> > 現在実行しているか実行しようとしているコマンドです。
>> > ただし、トラップの結果として、シェルが実行しているコマンドについては
>> > 話が別で (当てはまらず)、その場合 (変数に入っているの) は、トラップの
>> > 発動時に実行していたコマンドになります。
>>
>> この文を元に変更しました。
>
> 変更した文章 (or 部分) だけでよいので、
> メールに載せて頂けると助かります。
わかりました。
この部分は以下の文章を反映しています。
ただし、トラップによってシェルが実行しているコマンドは別で、
その場合は、トラップの発動時に実行していたコマンドになります。
長南さん:
>>>> .B COMP_KEY
>>>> .\"O The key (or final key of a key sequence) used to invoke the current
>>>> .\"O completion function.
>>>> 現在の補完関数を呼び出したキー (またはキーシーケンスの最後のキー) です。
>
>>> bash の info を見てみたら、COMP_KEY と COMP_TYPE の順番が逆に
>>> なっていました。
>>>
>>> つまり、COMP_TYPEの「補完のタイプに応じて補完関数が呼び出される」
>>> という記述が先になり、その後に COMP_KEY の「現在の補完関数を呼び
>>> 出したキーです」が現れます。これなら、唐突さはありません。
>>> man ページをまとめた方が、順番が逆になったこと対する気配りを
>>> 忘れたわけで、翻訳する側としては、これは仕方がないですね。
>>> まあ、工夫の余地がないわけではありませんけれど。たとえば、
>>> man ページも順番を逆にしてしまうとか。
>>
>> 初出用語は説明すべきというのはひとつの意見ではあります。そのフォーマッ
>> トとしては「（後述の〜を参照）」が適切かと思います。
>
> それもありますね。ほかにもいろいろな方法があるでしょうが、
> 読者が一番戸惑わないですむ方法が、一番よい方法だと思います。
>
>> ただ、そこまで原文に追加・変更を加えることは望ましくないと私は思います。
>> また、たとえば一例として上記「トラップ」なども初出で説明していないこと
>> から、実施すると原文に対して大掛かりな変更になってしまい、望ましくない
>> と思います。
>
> ええ、トラップについては、原文が注を付けておくべきだったと思います
> (訳文に「組み込みコマンド trap を参照」と訳注を付けてもよいですね)。
>
> 原文に大掛かりな変更を加えるのに反対だというのも賛成します。
>
> でも、わたしとしては、「読者にわかること、読みやすいこと」を
> 重視しています。ですから、その方がわかりやすくなるのなら、原文にない
> (と言うより、原文の裏にある) 言葉を (一つや二つなら) 補足してもよいし、
> 訳注も (読みにくくならない範囲で) どんどん付ければよい、と思っています。
> ただし、翻訳していて気がついたときにやればよい、ぐらいの安直な考え方
> ですけれど。
>
> この場合は、仮に項目の順番を変更するとしても、それほど大掛かりな
> 変更にはならないのではないでしょうか。
>
> とは言え、「やった方がよいのではないか」ぐらいの話です。決定権は
> 当然ながら、翻訳者にあるのですから、よいと思ったとおりになされば
> よいと思います。
元木さん:
>> 「関数」が正しいとすれば、これは翻訳の問題ではなく、原文の問題ですね。
>> 「補完関数」という言葉は、ここで初めて唐突に出てきます。読者は
>> 補完のメカニズムがわかっていないわけですから、かなり戸惑うと思います。
>> 一般ユーザに TAB を押して補完機能を使っているという意識はあっても、
>> 補完関数を使っているという意識はないでしょうし。
>>
>> bash の info を見てみたら、COMP_KEY と COMP_TYPE の順番が逆に
>> なっていました。
>>
>> つまり、COMP_TYPEの「補完のタイプに応じて補完関数が呼び出される」
>> という記述が先になり、その後に COMP_KEY の「現在の補完関数を呼び
>> 出したキーです」が現れます。これなら、唐突さはありません。
>> man ページをまとめた方が、順番が逆になったこと対する気配りを
>> 忘れたわけで、翻訳する側としては、これは仕方がないですね。
>> まあ、工夫の余地がないわけではありませんけれど。たとえば、
>> man ページも順番を逆にしてしまうとか。
>
> 私も逆順にしてしまった方が分かりやすいように感じました。
> 翻訳の方にコメントで意図的に逆順にしていると書いておけば、
> 今後の更新の際にも混乱することもないと思います。
変数名がアルファベット順に並んでいるので、それを変えてしまうと、
マニュアルとしてリファレンス性が下がってしまうと危惧しています。
一方、確かに bashref.info では COMP_TYPE の後に COMP_KEY を置いて
いますね。man と info の性質の違いなのかもしれません。
長南さん:
>>>>> .B COMP_TYPE
>
>>>>> .\"O \fI@\fP, to list completions if the word is not unmodified,
>
>>>>> \fI@\fP は、途中での一致がないときの候補のリスト表示です。
>
>>>> しかし、そうだとすると、これは原文が間違っているのでしょうか (not と
>>>> un のどちらかが不要)。それとも、「目下補完中の単語をユーザが
>>>> 何か文字を打ち込むことによって変更しないでもない (変更する必要がある)
>>>> ときは」ということなんでしょうか。それでは、show-all-if-unmodified と
>>>> 矛盾するだろうし ... いづれにしても、これは原文が意味不明瞭ですから
>>>> (わたしの読解力が足りないのかもしれませんが)、原文を離れ、実際の動作に
>>>> 即してお訳しになったのも、当然だと思います。
>>>
>>> 手元の英和辞典いくつかによると、「modify」は「修飾する、意味を限定する」
>>> という意味があるとのこと、「unmidified」は「限定されていない」という意
>>> 味があるとのことでした。
>>>
>>> そのため、“unmodified”=“限定されてない”=“途中までの一致がある”と
>>> 考えました。
>
> たとえば、「修飾語 (modifier) によって名詞の意味を限定 (modify) する」
> といった「変更、調節」の意味のバリエーションですね。ただ困ったことに、
> "unmodified" = "限定されていない" = "途中までの一致がない" と、逆にも
> 考えられます。その線で行けば、not ummodified は、要するに modified で、
> つまり "限定されている" = "途中までの一致がある"になる。それで、
> 原文が間違っているのではないかと考えたわけです。
>
>> 別メールでコメントしていますが、もう少し考えてみました。
>>
>> show-all-if-unmodified の説明を合わせて考えると、
>> "unmodified" = "without any possible partial completion"
>> ではないでしょうか。
>>
>> 「途中までの一致がある」だと、「複数の選択候補があり、これ以上補完できない」
>> という原文のニュアンスが失われているように感じました。
>
> [JM:00446] から引用。
>>
>> show-all-if-unmodified の説明を参考にして、少し意訳を考えてみました。
>> 「(部分的な補完が行われず) 補完対象の単語が変更されていない状況での
>> リスト表示」
>
> これ、ほんとに難しいですね。if the word is not unmodified が
> if the word is not modified の間違いだとして、show-all-if-unmodified
> の説明を見ると、
>
> If set to On, words which have more than one possible completion
> without any possible partial completion (the possible completions
> don't share a common prefix) cause the matches to be listed
> immediately instead of ringing the bell.
>
> となっていますから、いっそのこと modify から離れて、「部分的な
> 補完ができない場合に、補完候補のリストを表示します」と言って
> しまったらどうでしょう。「途中までの一致がないときの候補のリスト表示」
> と同じ考え方ですし、ちょっと曖昧ですけれど。
> 考えてみれば、「部分的に補完する」のは、まさに modify することですから、
> modify の訳ですと言えないこともありませんし。
元木さん:
> 別メールでコメントしていますが、もう少し考えてみました。
>
> show-all-if-unmodified の説明を合わせて考えると、
> "unmodified" = "without any possible partial completion"
> ではないでしょうか。
>
> 「途中までの一致がある」だと、「複数の選択候補があり、これ以上補完できない」
> という原文のニュアンスが失われているように感じました。
長南さんの訳を元に「部分的な補完ができないときの候補のリスト表示です」
と変更しました。
元木さん:
>> >>> .B COMP_POINT
>> >>> .\"O The index of the current cursor position relative to the beginning of
>> >>> .\"O the current command.
>> >>> .\"O If the current cursor position is at the end of the current command,
>> >>> .\"O the value of this variable is equal to \fB${#COMP_LINE}\fP.
>> >>> .\"O This variable is available only in shell functions and external
>> >>> .\"O commands invoked by the
>> >>> .\"O programmable completion facilities (see \fBProgrammable Completion\fP
>> >>> .\"O below).
>> >>> 現在のコマンドの先頭からの相対値として与えられた
>> >>> カーソル位置のインデックスです。
>> >>> 現在のカーソル位置が現在の現在のコマンドの最後にある場合、
>> >>> この変数の値は \fB${#COMP_LINE}\fP と等しくなります。
>> >>> この変数はプログラム補完機能 (後述の \fBプログラム補完\fP を参照)
>> >>> から呼ばれたシェル関数においてのみ有効です。
>>
>> >> この「インデックス」は先頭から何番目の文字かということですね。
>> >> それならば、正しい訳ですが、配列のインデックスとまぎらわしい
>> >> と思います。何か適当な訳語を工夫できないでしょうか。
>> >
>> > C をはじめ各プログラミング言語では文字列中の位置を「インデックス」
>> > と呼ぶことも多いこと、補完関数を書く人はプログラミング経験のある人が
>> > 対象であることから、「インデックス」でよいかと思います。
>>
>> このマニュアルはセクション 1 のマニュアルですから、一般ユーザが
>> 読むことを想定した方がよいのではないでしょうか。そう考えると、
>> 日本語の「インデックス」に「文字列中の位置」の意味を持たせるのは、
>> ちょっと無理だと思います。一般ユーザにもプログラマーにも通用する
>> 訳語を工夫するのは、翻訳者の腕の見せ所ですし。
>>
>> もっとも、一般ユーザはこんな細かい変数の説明まで読むわけがないと
>> 考えることもできますけれど。
>
> なぜ、原文の著者が the index of the current cursor position のように
> index を付けたのかが理解できませんでした。
> the index of を付けずに the current cursor position とだけ書いても、
> 文章の内容の正確性には全く影響を与えないように思います。
>
> 訳としても、
>
> 現在のコマンドの先頭からの相対値として与えられた現在のカーソル位置です。
>
> としてもよいように思います。
> ちょっと読みにくいので、
>
> 現在のカーソル位置の、現在のコマンドの先頭からの相対的な位置です。
>
> などを考えてみました。
長南さん:
>>>>> 現在のコマンドの先頭からの相対値として与えられた
>>>>> カーソル位置のインデックスです。
>>>>> 現在のカーソル位置が現在の現在のコマンドの最後にある場合、
>>>>> この変数の値は \fB${#COMP_LINE}\fP と等しくなります。
>>>>> この変数はプログラム補完機能 (後述の \fBプログラム補完\fP を参照)
>>>>> から呼ばれたシェル関数においてのみ有効です。
>
>>>> C をはじめ各プログラミング言語では文字列中の位置を「インデックス」
>>>> と呼ぶことも多いこと、補完関数を書く人はプログラミング経験のある人が
>>>> 対象であることから、「インデックス」でよいかと思います。
>>>
>>> このマニュアルはセクション 1 のマニュアルですから、一般ユーザが
>>> 読むことを想定した方がよいのではないでしょうか。そう考えると、
>>> 日本語の「インデックス」に「文字列中の位置」の意味を持たせるのは、
>>> ちょっと無理だと思います。一般ユーザにもプログラマーにも通用する
>>> 訳語を工夫するのは、翻訳者の腕の見せ所ですし。
>>>
>>> もっとも、一般ユーザはこんな細かい変数の説明まで読むわけがないと
>>> 考えることもできますけれど。
>>
>> Ruby 言語の初心者向け入門書としてロングセラーの「たのしい Ruby 第 3 版」
>> で、前のメールで例示した“文字列中から文字を探す機能”の説明を確認して
>> みました。同書では、「一致する部分の先頭のインデックスを返し」という言
>> 葉になっていました。これは一例ですが、プログラミング初心者向けの用語と
>> して一般的ではないかと考えます。
>
> うーん、セクション 1 の man ページが想定している読者は、プログラミング
> 初心者ではなく、一般ユーザだ (を含む) と言うことなんです。
> それにしては、bash の man ページには難しいことが書いてあるわけで、
> 一般ユーザ用というのは、タテマエにすぎませんけれど。でも、それでも、
> 翻訳では一般ユーザを意識せずにはいられないわけです。
>
> # わたしは、まさにその一般ユーザなんですが、ほかではインデックスが
> # 添字の意味で使われているので、ここでは戸惑いました。
「インデックス＝添字」ではなく、「インデックスによる配列では添字として
インデックスを指定する」という関係だと思います。連想配列では添字として
キーを指定します。
> それに、その Ruby の参考者ですが、もっと前の部分で「インデックス」
> という言葉をどういう意味で使うか、説明 (あるいは、暗示) している
> のではないでしょうか。あるいは、インデックスという言葉の意味が、
> 読んでいるうちに読者に何となくわかってくるように書いてあるとか。
>
> この bash の man の場合、インデックスは、すぐ近くでほとんどの場合
> 添字の意味で使われていますし、インデックスと言う言葉を使わなくても、
> 普通の日本語で説明できるわけですし。
>
> どちらの問題も、訳を変えるには、考え方を大きく変更しなければ
> なりませんから、結論はしばらく時間を置いてからになさればよいと
> 思います。その間に、こちらも先に進んでおきますから。
改めて考えてみると、
長南さん：配列と文字列で共通して“インデックス”と言うのは不自然
私：配列と文字列で共通して“インデックス”と言わないのは不自然
というのが互いの論点の違いと思いました。
元木さん:
>> >>>> .B COMP_WORDBREAKS
>> >>>> .\"O The set of characters that the \fBreadline\fP library treats as word
>> >>>> .\"O separators when performing word completion.
>> >>>> .\"O If
>> >>>> .\"O .SM
>> >>>> .\"O .B COMP_WORDBREAKS
>> >>>> .\"O is unset, it loses its special properties, even if it is
>> >>>> .\"O subsequently reset.
>> >>>> 単語補完のときに \fBreadline\fP ライブラリが単語分割の区切り文字として
>> >>>> 扱う文字の並びです。
>> >>>> .SM
>> >>>> .B COMP_WORDBREAKS
>> >>>> を unset すると、この変数の特殊な性質はなくなります。後で再び
>> >>>> set しても元には戻りません。
>> >>>
>> >>> 原文の問題かもしれませんが、「この変数の特殊な性格はなくなります」
>> >>> というのは、具体的にどういうことなんでしょう。
>> >>> special properties という言葉は、変数 DIRSTACK, FUNCNAME, GROUPS,
>> >>> HISTCMD, RANDOM, SECONDS でも使われています。
>> >>
>> >> わかりやすいところで、SECONDS の動作は以下のとおりです。
>
> [...]
>
>> >> 一度 unset したあとに値を設定すると、経過秒数を返す性質はなくなります。
>> >
>> > 説明をうかがえば、正しい訳だとわかりますが、「この変数の特殊な性格は
>> > なくなります」という言い方は漠然としすぎていると思います。
>> > こういうとき日本語では「bash に対する (とって) 特別な意味は (効果は、
>> > 働きは、関係は) なくなります (失われます)」などと言うのではないで
>> > しょうか。つまり、「特殊な」か「特別な」か「特有の」か、「性質」か
>> > 「性格」か、あるいは properties をもっと具体的に表現した方がよいのか。
>> > もうすこし訳語を練る余地があると思います。
>>
>> 通常の（special ではない）変数と対比して「特殊」という意味だと思い、い
>> ろいろ考えると「special」を「特殊」と訳すのが自然かと思いました。
>> 「固有」という訳も考えましたが、「固有」だと「通常の（special ではな
>> い）変数」との対比ではなく、それぞれの変数が違うニュンアンスになってし
>> まうように感じました。
>
> 長南さんが気にされているのは、special の訳と、properties の訳の両方ですね。
>
> properties の方ですが、
> 日本語で「性質」というと、化学物質等の振る舞いを連想させることが多く、
> 変数の「性質」というのはあまり言わない表現だと思います。
> どちらかというと、変数が持つ「役割」とか「意味」の方がしっくり来る気がします。
ここでいう「特殊な性質」を持つ変数と、通常の変数を比較すると、以下のよ
うな違いがあると思います。
通常の変数：代入された値を格納し、参照されると格納された値を返す
特殊な変数：値を格納せず、参照されると、bash の処理を実行した値を返す
（代入すると通常の変数となるものもある）
Linux でいうと、通常のファイルと、/dev や /proc などとの違いかと思いま
す。この両者が違うことを説明するのには、「役割が違う」というと間接的で、
「性質が違う」といったほうが直接的だと考えます。
> special の方は、「特別な」か「特殊な」あたりかなと思います。
>
> 全体としては「変数が持つ特別な役割がなくなります」を推しておきます。
> 特別→特殊、役割→意味 に置き換えても誤解は生まないと思います。
長南さん:
>>>>> 単語補完のときに \fBreadline\fP ライブラリが単語分割の区切り文字として
>>>>> 扱う文字の並びです。
>>>>> .SM
>>>>> .B COMP_WORDBREAKS
>>>>> を unset すると、この変数の特殊な性質はなくなります。後で再び
>>>>> set しても元には戻りません。
>
>>>> 説明をうかがえば、正しい訳だとわかりますが、「この変数の特殊な性格は
>>>> なくなります」という言い方は漠然としすぎていると思います。
>>>> こういうとき日本語では「bash に対する (とって) 特別な意味は (効果は、
>>>> 働きは、関係は) なくなります (失われます)」などと言うのではないで
>>>> しょうか。つまり、「特殊な」か「特別な」か「特有の」か、「性質」か
>>>> 「性格」か、あるいは properties をもっと具体的に表現した方がよいのか。
>>>> もうすこし訳語を練る余地があると思います。
>>>
>>> 通常の（special ではない）変数と対比して「特殊」という意味だと思い、い
>>> ろいろ考えると「special」を「特殊」と訳すのが自然かと思いました。
>>> 「固有」という訳も考えましたが、「固有」だと「通常の（special ではな
>>> い）変数」との対比ではなく、それぞれの変数が違うニュンアンスになってし
>>> まうように感じました。
>>
>> 長南さんが気にされているのは、special の訳と、properties の訳の両方ですね。
>>
>> properties の方ですが、
>> 日本語で「性質」というと、化学物質等の振る舞いを連想させることが多く、
>> 変数の「性質」というのはあまり言わない表現だと思います。
>> どちらかというと、変数が持つ「役割」とか「意味」の方がしっくり来る気がします。
>>
>> special の方は、「特別な」か「特殊な」あたりかなと思います。
>>
>> 全体としては「変数が持つ特別な役割がなくなります」を推しておきます。
>> 特別→特殊、役割→意味 に置き換えても誤解は生まないと思います。
>
> ええ、property の訳は、とても難しいと思います。「性質」や「性格」で
> すむときはよいのですが、property の概念と「性質、性格」の概念は
> かなり違っていて、property の概念には「性質」や「性格」の概念に
> 存在しないものが含まれている。たとえば、あるものが他のものに
> 対して持っている役割とか、意味とか、関係とか。ファイルならそれが
> 作成された時間とか、所有者とか。「属性」の方が意味が近いでしょうが、
> これもぴったり一致するわけではありませんし。
>
> そんなわけで、わたしなど、困ったときは「プロパティ」とカタカナにして
> すませてしまいますが、この場合のように、その手が使えないときもある
> わけです。そういうときは、ほんとうに難しい。その場合における property
> の具体的な意味を考えて、訳語を工夫するよりないだろうと思います。
>
> この場合なら、SECONDS を例に取れば、bash が稼働秒数を代入し続ける
> という特性を SECONDS という変数は持っている。COMP_WORDBREAKS ならば、
> 単語補完のときに readline ライブラリが、区切り文字として使用する
> 文字群を保持するという特性を持っている。そして、unset すると、bash に
> 対するそうした特別な関係がなくなってしまう。ほかの変数のことも考えに
> 入れると、やっぱり、「役割」か「意味」というところでしょうか。
> 「関係」もありそうです。
>
> ただ、わたしとしては、「この変数が bash に対して持つ特別な役割」
> と「bash に対して持つ」を補足した方がよいと思います。
特殊（特別）な性質は、bash に対して持つのではなく、通常の変数と比較して
持つと私は考えています。
たとえば私は、「/dev/zero は（通常のファイルと違い）Linux に対して特別
な役割を持ちます」という説明より、「/dev/zero は（通常のファイルと違
い）特殊な性質を持ちます」という説明が自然だと思います。
長南さん:
>> 単語補完のときに \fBreadline\fP ライブラリが単語分割の区切り文字として
>> 扱う文字の並びです。
>> .SM
>> .B COMP_WORDBREAKS
>> を unset すると、この変数の特殊な性質はなくなります。後で再び
>> set しても元には戻りません。
>
> 「英和活用大辞典」から property の文例 を引きます。たいていは、
> 「特性」と訳しているので、そういうのは省略。peoperty という言葉の
> 言わば有効範囲を知るためですから、変わった訳例のみ。
>
> These hotsprings are said to possess healing propertis.
> この温泉は病気に効くそうだ。
>
> herbs with magical properties
> 魔法のような力を持つ薬草
>
> The food is poor in nourishing [nutritious] properties.
> その食物は栄養分に乏しい。
>
> property は、場合によっては「効果、効能、能力、成分」などとも
> 訳せそうです。どれも問題の訳語には使えそうもありませんが。
>
> ところで、「この変数の特殊な性質はなくなります」をわたしが
> 問題だと思った理由は、「特殊な性質」とは何なのか、何がどう特殊
> なのかが、この文章からではまったくわからないからでした。
>
> あらためて、原文を見直すと、こちらもかなり曖昧です。でも、言いたい
> ことがわからないでもない。それで、よくよく見ると、it loses the special
> propertiesではなく、it loses its special properties と言っているのに
> 気づきます。これではないでしょうか。問題は、propertis の訳というより、
> its の訳にあるのではないでしょうか。its を表に出して訳してみます。
>
> COMP_WORDBREAKS を unset すると、この変数はそれが持つ特性を
> 失います。
>
> まだ、どういう特性かがはっきりしません。
>
> COMP_WORDBREAKS を unset すると、この変数は bash に対してそれが持つ
> 特性を失います (あるいは、「それが」を省略して、「bash に対して
> 持っている特性を失います」)。
>
> あるいは、
>
> COMP_WORDBREAKS を unset すると、この変数が bash に対して持っている
> 特性が失われます。
>
> いかがでしょうか。まだ曖昧ですが、一応通るのではないでしょうか。
> 原文は properties ではなく、special properties ですから、「特性」より
> 「特別な性質」と special を強調した方がよいかもしれませんし、
> やっぱり、「特別な役割 (意味、関係)」などの方が明解で、読者に親切
> かもしれませんけれど。
>
> 結局のところ、提案した訳については、元木さんの案と大して変わりません。
> ただ、原文が the ではなく its であることに注目していただきたかったのです。
特性という訳もナシではないとは思います。が、私としては上述したように、
special を強調したいと考えます。
元木さん:
>> >>>> .B FUNCNAME
>
> [...]
>
>> >>>> .\"O This variable can be used with \fBBASH_LINENO\fP and \fBBASH_SOURCE\fP.
>> >>>> .\"O Each element of \fBFUNCNAME\fP has corresponding elements in
>> >>>> .\"O \fBBASH_LINENO\fP and \fBBASH_SOURCE\fP to describe the call stack.
>> >>>
>> >>>> この変数は \fBBASH_LINENO\fP や \fBBASH_SOURCE\fP と組になっています。
>> >>>> \fBFUNCNAME\fP の各要素は \fBBASH_LINENO\fP や \fBBASH_SOURCE\fP
>> >>>> の各要素に対応し、呼び出しスタックを表します。
>> >>>
>> >>> can be used with と「組になっている」では微妙に違うのではないでしょうか。
>> >>> 確かに、一番言いたいのは、そういうことなんでしょうけれど。
>> >>
>> >> 3 つの変数が関連している含みを持たせて、上記のようにしてあります。
>> >>
>> >>> describe というのは、「小学館ランダムハウス英和辞典」には、
>> >>> 「対象物の外観・性質・属性などを明かにするためのイメージまたは印象を
>> >>> 言葉によって伝達すること」と注が付いていますから、「表す」というより
>> >>> 「説明する」に近いと思います。ここでは、「FUNCNAME の各要素は、
>> >>> BASH_LINENO や BBASH_SOURCE に対応する要素を持ち、(その三つが一緒に
>> >>> なって) call stack についての情報を提供している」ということでは
>> >>> ないでしょうか。「例えば、${FUNCNAME[$i]} は」以下が、その情報の
>> >>> 具体例になるわけです。
>> >>
>> >> “要素が情報を提供する”というのは違和感があります。
>> >
>> > 違和感があるかどうかはたいした問題ではありません。
>>
>> そうですか。
>>
>> > 訳し方について
>> > わたしの考えを示すために書いた訳例にすぎませんから。
>> >
>> > 問題は、「FUNCNAME の各要素は ... 呼び出しスタック (そのもの) を
>> > 表す」のではなく、呼び出しスタックについての情報を保持・提供
>> > しているだけだということです。だから、原文は indicate とか mean
>> > ではなく、describe という言葉を使っているわけです。
>> >
>> > 何でも構いませんが、describe の訳語として、「述べる、記述する、
>> > 描写する、説明する」といった意味を含みに持つ表現を捜す必要が
>> > あると思います。
>> >
>> > 「BFUNCNAME の各要素は ... 呼び出しスタックについての (に関する)
>> > 情報を表しています」や「... 情報を保持しています」はあるかも
>> > しれません。前者はちょっと苦しい気がするし、後者は describe から
>> > かなり離れてしまいますが。
>>
>> 手元の英和辞典いくつかに「表現する」という訳語があったため、
>> 「表現します」と変更しました。
>
>> >>>> .\"O This variable can be used with \fBBASH_LINENO\fP and \fBBASH_SOURCE\fP.
>> >>>> .\"O Each element of \fBFUNCNAME\fP has corresponding elements in
>> >>>> .\"O \fBBASH_LINENO\fP and \fBBASH_SOURCE\fP to describe the call stack.
>
>> >>>> この変数は \fBBASH_LINENO\fP や \fBBASH_SOURCE\fP と組になっています。
>> >>>> \fBFUNCNAME\fP の各要素は \fBBASH_LINENO\fP や \fBBASH_SOURCE\fP
>> >>>> の各要素に対応し、呼び出しスタックを表します。
>
> 各要素は呼び出しスタックの各要素に対応しているのであり、
> 呼び出しスタック(全体)を表現しているわけではないですね。
> なかなか難しいですが、describe のニュアンスを出しながら、意訳してみました。
>
> FUNCNAME の各要素には BASH_LINENO と BASH_SOURCE に対応する要素があり、
> これらを参照することで、呼び出しスタックの状態を確認できます。
どうも「表現」だと違和感があるようですね。
いただいた訳だと、“FUNCNAME”⊃“BASH_LINEO や BASH_SOURCE に相当する
情報”と誤解するおそれがあると思いましたので、以下のように変更しました。
この変数の各要素は、BASH_LINENO や BASH_SOURCE の各要素に対応します。
これらを参照することで、呼び出しスタックの状態を確認できます。
長南さん:
>>>> この変数は \fBBASH_LINENO\fP や \fBBASH_SOURCE\fP と組になっています。
>>>> \fBFUNCNAME\fP の各要素は \fBBASH_LINENO\fP や \fBBASH_SOURCE\fP
>>>> の各要素に対応し、呼び出しスタックを表します。
>
>>> 手元の英和辞典いくつかに「表現する」という訳語があったため、
>>> 「表現します」と変更しました。
>
>> 各要素は呼び出しスタックの各要素に対応しているのであり、
>> 呼び出しスタック(全体)を表現しているわけではないですね。
>
> ええ、そういう意味で、「FUNCNAME の各要素は ... 呼び出しスタックを
> 表します」はアウトですが、「FUNCNAME の各要素は ... 呼び出しスタックを
> 表現しています」は、ぎりぎりセーフだと思います。当たらずと言えど、
> 遠からずで。
>
> でも、いづれにしろ、辞書にある訳語がどれもこの場合ぴったりして
> いないわけですから、こういう場合には、自分で訳語を工夫する必要が
> あると、わたしとしては言いたかったわけです。そして、わたしの試訳は、
> その一例だと。
>
> # たぶん、自分で訳語を工夫するには、しっかりした英英辞典に当たって、
> # 問題の言葉の中心的な意味を押さえ、さらに、英語の文例や和訳例も
> # 調べてみる必要があるでしょう。
>
> # 訳例を調べるには、「英辞郎」がとても役に立ちます。
> # http://www.alc.co.jp/
>
>> なかなか難しいですが、describe のニュアンスを出しながら、意訳してみました。
>>
>> FUNCNAME の各要素には BASH_LINENO と BASH_SOURCE に対応する要素があり、
>> これらを参照することで、呼び出しスタックの状態を確認できます。
>
> これも一つの工夫ですね。
長南さん:
>> この変数は \fBBASH_LINENO\fP や \fBBASH_SOURCE\fP と組になっています。
>> \fBFUNCNAME\fP の各要素は \fBBASH_LINENO\fP や \fBBASH_SOURCE\fP
>> の各要素に対応し、呼び出しスタックを表します。
>
> ある英単語がどんな風に使われるかを調べたいときは (ということは、
> 訳し方を調べるということでもありますが)、研究社の「英和活用大辞典
> (Dictionary of English Collocations)」が、大変役に立ちます。
>
> その「英和活用大辞典」の describe の項にこんな文例が出ています。
>
> He described the missing child to the police.
> その行方不明の子供の特徴を警察に語った。
>
> つまり、英単語一語を日本語二語に訳すと、通りがよい場合もある
> ということです。わたしの挙げた訳例、
>
> FUNCNAME の各要素は ... 呼び出しスタックについての情報を提供している。
>
> も、そこを見ていただきたかったのです (訳語の選択そのものは二の次にして)。
>
> 元木さんの試訳も (原文とは別の視点から表現するという手法を採用
> なさったものですが)、
>
> FUNCNAME の各要素には BASH_LINENO と BASH_SOURCE に対応する要素があり、
> これらを参照することで、呼び出しスタックの状態を確認できます。
>
> 「参照することで ... 状態を確認」と二語以上に展開して訳して
> いらっしゃるわけです。
>
> この describe の訳には、「情報」とか「状態」とか、何か言葉を補う
> 必要があるのだと思います。
二語以上に訳すことは問題ないと思います。
元木さん
>> >>>> .B LINENO
>> >>>> .\"O Each time this parameter is referenced, the shell substitutes
>> >>>> .\"O a decimal number representing the current sequential line number
>> >>>> .\"O (starting with 1) within a script or function. When not in a
>> >>>
>> >>>> この変数が参照されると、
>> >>>> シェルはスクリプトや関数における現在の行番号 (1から始まります) を表す
>> >>>> 10 進値を代入します。スクリプトや関数の内部でない場合には、
>>
>> >>> この変数が参照されるたびに、シェルはスクリプトや関数における現在の
>> >>> 行番号 (1 から始まります) を表す10 進数を代入し直します。
>> >>>
>> >>> 一例として前の訳をいじってみましたが、この方が具体的でしょう。
>> >>
>> >> 前のメールに書いたように、「代入」はおかしいと思います。
>> >> each や substitute を生かすということで、以下のように変更します。
>> >>
>> >> この変数が参照されると、その場所ごとに、
>> >> スクリプトや関数における現在の行番号 (1 から始まります) を表す
>> >> 10 進値に置き変わります。
>> >
>> > 「Each」のニュアンスが「current」に含まれるとのコメントがありましたが、
>> > 著者が「Each time ...」といっているのは、普通のシェル変数は値を保持していて、
>> > 何度参照されても保持している値を返すだけなのに対して、
>> > LINENO の場合には、変数が参照された際に、(保持している値を返すのではなく)
>> > 「その都度」変数の内容を更新して返す、ということを言いたかったのでは
>> > ないでしょうか。
>> >
>> > substitute についてですが、
>> > 変数の内容を変更する行為は「代入」(substitution) というと思います。
>> > LINENO という変数を参照する側から見ると、LINENO の内容が更新されているので、
>> > 「代入」という表現は正しいのではないでしょうか。
>>
>> 「『代入』(substitution)」というのは、どこの英和辞書に出ていましたか。
>> うちの「小学館ランダムハウス」の substitution には、「代理、代用、
>> 取替え、交換、置換」しか出ていませんでした。それで、ちょっと気になって、
>> 研究社「新和英大辞典 (第四版)」を引いてみたら、「代入」は
>> 「[数] substitution」と訳してあります。びっくりしました。Web の
>> 「英辞郎」でも、やっぱり substitute に「代入」がありました。
>> 「代入」assign だけではないのですね。思い込みで「代入では言葉が
>> 足りない」などと言って、高橋さんには悪いことをしました。
>
> 代入は substitution と assignment がありますが、
> コンピュータでは assignment を使うことが多いと思います。
> 変数の代入は普通 assignment ですね。
>
> 個人的な印象と断っておきますが、
> assignment の方は変数の参照先を返るイメージですが、
> substitute だと置き換えるといったイメージを持っています。
>
> ただ、著者もそこまで厳密に考えずに文を書いているかもしれませんので、
> substitute と assignemnt を同じような意味で書いているかもしれません。
>
>> > 案を考えてみました。いかがでしょうか？
>> >
>> > この変数が参照されるたびに、シェルはスクリプトや関数における現在の行番号
>> > (1 から始まります) を表す 10 進数をこの変数に代入します。
>>
>> 「たびに」があれば、「代入し直す」という必要はなかったのですね。
>> でも、高橋さんの訳をちょっと変更した
>>
>> この変数は、参照されるたびに、スクリプトや関数における現在の行番号
>> (1 から始まります) を表す 10 進数に置き換わります。
>>
>> もあると思います。「シェルは ... この変数に」と主語と対象を出した方が
>> 明晰でしょうけれど。
>
> そうですね。
> substitute は、交代要因を送り込むとか、入れ替わる／置き換わるといった
> イメージですし、それを反映しているようにも思います。
> 要は、毎回呼ばれるたびに更新されることが伝わればよいかと。
元木さん:
>> >>>> .B LINENO
>> >>>> .\"O Each time this parameter is referenced, the shell substitutes
>> >>>> .\"O a decimal number representing the current sequential line number
>> >>>> .\"O (starting with 1) within a script or function. When not in a
>> >>>
>> >>>> この変数が参照されると、
>> >>>> シェルはスクリプトや関数における現在の行番号 (1から始まります) を表す
>> >>>> 10 進値を代入します。スクリプトや関数の内部でない場合には、
>> >>>
>> >>> Each は生かした方がよいと思います。assigns ではなく、substitutes
>> >>> ですから、「代入」を使うなら、「代入し直す」では。
>> >>
>> >> 「Each」のニュアンスは「current」に含まれるとして、「代入」はおかしいで
>> >> すね。
>> >> 「〜10 進値になります」に変更します。
>> >
>> > これは元訳のままだったのですね。each にしろ、substitute にしろ、
>> > 具体的な意味を持っているのですから、きちんと訳出しないと、文章から
>> > 具体性が失われると思います。substitude は、変数に既に入っている値を
>> > 現在の値で入れ替えると言っているのでしょう。だからこそ、each time の
>> > 意味が利いてくるのですし。
>> >
>> > この変数が参照されるたびに、シェルはスクリプトや関数における現在の
>> > 行番号 (1 から始まります) を表す10 進数を代入し直します。
>> >
>> > 一例として前の訳をいじってみましたが、この方が具体的でしょう。
>>
>> 前のメールに書いたように、「代入」はおかしいと思います。
>> each や substitute を生かすということで、以下のように変更します。
>>
>> この変数が参照されると、その場所ごとに、
>> スクリプトや関数における現在の行番号 (1 から始まります) を表す
>> 10 進値に置き変わります。
>
> 「Each」のニュアンスが「current」に含まれるとのコメントがありましたが、
> 著者が「Each time ...」といっているのは、普通のシェル変数は値を保持していて、
> 何度参照されても保持している値を返すだけなのに対して、
> LINENO の場合には、変数が参照された際に、(保持している値を返すのではなく)
> 「その都度」変数の内容を更新して返す、ということを言いたかったのではないでしょうか。
>
> substitute についてですが、
> 変数の内容を変更する行為は「代入」(substitution) というと思います。
> LINENO という変数を参照する側から見ると、LINENO の内容が更新されているので、
> 「代入」という表現は正しいのではないでしょうか。
>
> 案を考えてみました。いかがでしょうか？
>
> この変数が参照されるたびに、シェルはスクリプトや関数における現在の行番号
> (1 から始まります) を表す 10 進数をこの変数に代入します。
>>>>> .B LINENO
>>>>> .\"O Each time this parameter is referenced, the shell substitutes
>>>>> .\"O a decimal number representing the current sequential line number
>>>>> .\"O (starting with 1) within a script or function. When not in a
>>>>
>>>>> この変数が参照されると、
>>>>> シェルはスクリプトや関数における現在の行番号 (1から始まります) を表す
>>>>> 10 進値を代入します。スクリプトや関数の内部でない場合には、
>
>>>> この変数が参照されるたびに、シェルはスクリプトや関数における現在の
>>>> 行番号 (1 から始まります) を表す10 進数を代入し直します。
>>>>
>>>> 一例として前の訳をいじってみましたが、この方が具体的でしょう。
>>>
>>> 前のメールに書いたように、「代入」はおかしいと思います。
>>> each や substitute を生かすということで、以下のように変更します。
>>>
>>> この変数が参照されると、その場所ごとに、
>>> スクリプトや関数における現在の行番号 (1 から始まります) を表す
>>> 10 進値に置き変わります。
>>
>> 「Each」のニュアンスが「current」に含まれるとのコメントがありましたが、
>> 著者が「Each time ...」といっているのは、普通のシェル変数は値を保持していて、
>> 何度参照されても保持している値を返すだけなのに対して、
>> LINENO の場合には、変数が参照された際に、(保持している値を返すのではなく)
>> 「その都度」変数の内容を更新して返す、ということを言いたかったのでは
>> ないでしょうか。
>>
>> substitute についてですが、
>> 変数の内容を変更する行為は「代入」(substitution) というと思います。
>> LINENO という変数を参照する側から見ると、LINENO の内容が更新されているので、
>> 「代入」という表現は正しいのではないでしょうか。
>
> 「『代入』(substitution)」というのは、どこの英和辞書に出ていましたか。
> うちの「小学館ランダムハウス」の substitution には、「代理、代用、
> 取替え、交換、置換」しか出ていませんでした。それで、ちょっと気になって、
> 研究社「新和英大辞典 (第四版)」を引いてみたら、「代入」は
> 「[数] substitution」と訳してあります。びっくりしました。Web の
> 「英辞郎」でも、やっぱり substitute に「代入」がありました。
> 「代入」assign だけではないのですね。思い込みで「代入では言葉が
> 足りない」などと言って、高橋さんには悪いことをしました。
>
>> 案を考えてみました。いかがでしょうか？
>>
>> この変数が参照されるたびに、シェルはスクリプトや関数における現在の行番号
>> (1 から始まります) を表す 10 進数をこの変数に代入します。
>
> 「たびに」があれば、「代入し直す」という必要はなかったのですね。
> でも、高橋さんの訳をちょっと変更した
>
> この変数は、参照されるたびに、スクリプトや関数における現在の行番号
> (1 から始まります) を表す 10 進数に置き換わります。
>
> もあると思います。「シェルは ... この変数に」と主語と対象を出した方が
> 明晰でしょうけれど。
お二人は「変数の値が前の値から変わる」というニュアンスを強調されている
と解釈しました。ただし、変数の値を参照しているときに「変数に値が入る
（代入する、置き換わる）」と言うのは、参照なのにわざわざ代入（またはそ
れ相当）を持ち出す不自然さ（婉曲感）があると思います。
前述の /dev でいうと、「/dev/zero が参照されるたびに、0x00 の値が
/dev/zero に書き込まれます」と説明するのは不自然かと思います。
私の解釈は「スクリプトやコマンドライン中の LINENO が、参照結果として、
行番号に置き換わる」というニュアンスで、これであれば辻褄が合っていると
思います。
元木さん:
>> >>> .B READLINE_POINT
>> >>> .\"O The position of the insertion point in the
>> >>> .\"O .B readline
>> >>> .\"O line buffer, for use with
>> >>> .B readline
>> >>> の編集バッファでのポイントの位置です。
>> >>
>> >> insertion の訳がありませんが、なくても同じことですか。
>> >
>> > はい。
>>
>> インサーション・ポイント (挿入ポイント) なら、位置が限定されますが、
>> ポイントと言っただけでは、位置が限定されないのでないかと思うのですが。
>
> READLINE のセクションの Readline Command Names では、
> point は current cursor position だと説明があり、
> それ以降では point と mark のペアで説明がされています。
>
> 一方、insertion point や READLINE_POINT, READLINE_LINE は
> シェル変数および組み込みコマンドの節でしか登場しないので、
> READLINE セクションの説明の前提はおかない方がよいと思います。
>
> 訳としては、挿入ポイントか、(意訳するとしたら) 現在のカーソル位置、あたりでしょうか。
では、ここの部分を「挿入ポイント」と変更します。
元木さん:
>> >>>> .B SHLVL
>> >>>> .\"O Incremented by one each time an instance of
>> >>>> .\"O .B bash
>> >>>> .\"O is started.
>> >>>> .B bash
>> >>>> の実体が起動されるたびに 1 ずつ増えます。
>> >>>
>> >>> 「実体」というのは、instance の訳として熟しているのですか。
>> >>> instance の訳はむずかしいものです。この場合は、bash の中で
>> >>> bash を起動し、またそこから bash を起動する、それが何回行われたか
>> >>> ということのようですが。
>> >>
>> >> この instance はほぼプロセスと同じ意味かと思います。
>> >> bash を起動するとプロセスが起動するのは自明であり、
>> >> 「実体」という言葉の扱いが難しいようですので、
>> >> 「の実体」を削りました。
>> >
>> > こうなさったのですね。
>> >
>> > SHLVL bash が起動されるたびに 1 ずつ増えます。
>> >
>> > xterm から xterm を起動すれば、二番目の xterm の $SHLVL は 2 に
>> > なりますが (一番目の xterm の $SHLVL は 1 のまま)、WM のメニューや
>> > アイコンから xterm をいくつ起動しても、みんな $SHLVL は 1 です。
>> > ですから、訳には言葉がもう少し必要な気がします。
>> >
>> > ちょっと苦しまぎれですが、すぐ思いつくのは、「(bash から) bash が
>> > 起動されるたびに」とカッコを使うことです。あるいは、instance を
>> > 「インスタンス」とカタカナにしておく手もあると思います。読者に意味は
>> > 通じないかもしれませんが、少なくとも、bash が単に起動されることを
>> > 言っているのではないのだ、ということは伝わるでしょうから。
>> >
>> > 何かよい訳を思いつかれることを期待しています。
>>
>> 少し意訳が入りますが、“何に対して増えるのか”が誤解のもとのようなので、
>> 以下のように変更しました。
>>
>> bash が起動するときに、環境変数で渡された値から 1 増やした値が
>> 設定されます。
>
> 別メールでもコメント致しましたが、
> 個人的には、この表現は誤解も少なく、いい意訳かなと思います。
ありがとうございます。ではこれでいきたいと思います。
長南さん:
> たしかに正確ですね。でも、元木さんが [JM:00446] でお示しになった
> 「サブプロセスとして bash が起動されると、SHLVL が増える」という
> 考え方も、簡潔で捨てがたいと思います。その行き方なら、「サブプロセス
> として bash が起動されるたびに、1 すつ増えます」でしょうか。
元木さん:
> bash から bash を起動するごとに SHLVL が 1 ずつ増えるということですが、
> bash -> zsh -> bash と繰り返しても $SHLVL が増えて行きます。
> サブプロセスとして bash が起動されると、SHLVL が増えるということでしょうか。
>
> bash# echo $SHLVL
> 1
> bash# zsh
> zsh# echo $SHLVL
> 2
> zsh# bash
> bash# echo $SHLVL
> 3
> bash#
元木さんの指摘するように zsh が起動されても数値が増えることと、
「bash が起動されるたびに」という言い回し自体が“別の系列で
bash が起動される”場合の誤解を招くと思ったことから、前の意訳
を考えました。
以上、変更を GitHub 上のテキストにも反映しました。
https://github.com/emasaka/bash-jman/commit/821351e4b253a10fd19a1cb49a6447cf6e581ce1
--
Masakazu Takahashi (emasaka)