長南洋一
cyoic****@maple*****
2011年 10月 12日 (水) 20:28:12 JST
Fork長南です。
Takahashi さんのメールより [JM:00441]
>
>>> .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 は「管理」と訳してみました。
>> 「操作」という訳もあるかもしれません。
>>
>> bash が内部に持つ、コマンドのハッシュテーブルに対応する連想配列変数です。
>> 通常ハッシュテーブルはビルトインコマンド hash で管理します。
>>
>> # 「通常」という補足は、as maintained の as のニュアンスのつもりです。
>> # 違うかもしれませんが。
>
> 1 つ目の案を元に変更しました。
fBbash\fP が内部に持つ、コマンドのハッシュテーブルに対応する
連想配列変数です。
ハッシュテーブルは組み込みコマンド hash で操作します。
この配列に要素を追加すると、ハッシュテーブルにも追加されます。
配列から要素を削除すると、ハッシュテーブルから削除されます。
こうなさったのですね。これだと、三行目と四行目以下がうまくつながらない
のではないでしょうか。なぜなら、四行目以下はハッシュテーブルの操作法を
説明しています。三行目で「hash で操作する」と言いながら、それでは
おかしいでしょう。
それで、わたしは「通常ハッシュテーブルはビルトインコマンド hash で
管理します」と「通常」を補ったのです。文章の論理と言うか、流れを
はっきりさせるために、「すなわち」や「だから」、あるいは「〜のだ」
や「〜わけだ」を補うのは、翻訳ではよくあることですし、as という
関係詞は that や which と違って、「ような」とか「たとえば」とか
「だいたい」といった意味合いを持っています (俗用法では that と
同じ意味で使われることもあるそうですが)。それで、この場合なら、
「通常は」ぐらいだろうと考えたわけです。「通常」以外でも、三行目と
四行目以下が論理的にきちんとつながるなら、どんな言葉でもよいのですが。
maintain に「操作」ではなく「管理」を選んだのも、三行目と四行目以下を
区別しようという気持ちが働いたからです。もともと maintain という言葉は
「操作」より「管理」に近いでしょうし。
>> 翻って、BASH_ALIASES の訳についても同じことが言えます。
>> BASH_ALIASES の場合は、「組み込みコマンド alias で扱う」が
>> エイリアスに付いても、リストに付いても、意味が通るので気がつき
>> ませんでした。
>>
>>> .B BASH_ALIASES
>>> .\"O An associative array variable whose members correspond to the internal
>>> .\"O list of aliases as maintained by the \fBalias\fP builtin.
>>> .\"O Elements added to this array appear in the alias list; unsetting array
>>> .\"O elements cause aliases to be removed from the alias list.
>>> 組み込みコマンド \fBalias\fP で扱うエイリアスの内部的なリストに
>>> 対応する連想配列変数です。
>>> この配列に要素を追加すると、エイリアスのリストにも追加されます。
>>> 配列から要素を削除すると、エイリアスがリストから削除されます。
> 前者の案を元に変更しました。
こういうことですね。
エイリアスの内部的なリストに対応する連想配列変数です。
エイリアスは組み込みコマンド \fBalias\fP で操作します。
この配列に要素を追加すると、エイリアスのリストにも追加されます。
配列から要素を削除すると、エイリアスがリストから削除されます。
これも、二行目と三行目以下について、BASH_CMDS と同じことが言えます。
それから、「エイリアスの内部的なリスト」は、「エイリアスについて
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」の訳が抜けています。
>
> 前者の指摘で削っている部分が後者の指摘の部分かと思います。
素直に訳してみます (実際の動作の確認はしていません)。
現在実行しているか実行しようとしているコマンドです。
ただし、トラップの結果として、シェルが実行しているコマンドについては
話が別で (当てはまらず)、その場合 (変数に入っているの) は、トラップの
発動時に実行していたコマンドになります。
>>> .B BASH_LINENO
>>> .\"O An array variable whose members are the line numbers in source files
>>> .\"O where each corresponding member of
>>> .\"O .SM
>>> .\"O .B FUNCNAME
>>> .\"O was invoked.
>>> ソースファイル中の行番号に対応する要素からなる配列変数で、
>>> それぞれの要素は
>>> .SM
>>> .B FUNCNAME
>>> の各要素が呼び出された位置に対応します。
> すっきりしたほうがいいということで、「ソースファイル中の行番号からなる
> 配列変数で」と変更しました。
「要素」まで消せるんですね。そこまでは思い付きませんでした。
>>> .B COMP_KEY
>>> .\"O The key (or final key of a key sequence) used to invoke the current
>>> .\"O completion function.
>>> 現在の補完関数を呼び出したキー (またはキーシーケンスの最後のキー) です。
>>
>> この completion function は「関数」ではなく、「機能」ではないのですか。
>> キーとかキーシーケンスというのは、「Readline のコマンド名」の「補完」に
>> 書いてある complete (TAB) や possible-completions (M-?) の TAB や M-? の
>> ことなんでしょうか。そこでは complete などは、セクション名にあるように、
>> 関数ではなく、コマンドと呼んでいるようですが、Programmable Completion
>> の場合は関数なんですか。
>
> この function は関数ですね。コマンドでもいいです。
「関数」が正しいとすれば、これは翻訳の問題ではなく、原文の問題ですね。
「補完関数」という言葉は、ここで初めて唐突に出てきます。読者は
補完のメカニズムがわかっていないわけですから、かなり戸惑うと思います。
一般ユーザに TAB を押して補完機能を使っているという意識はあっても、
補完関数を使っているという意識はないでしょうし。
bash の info を見てみたら、COMP_KEY と COMP_TYPE の順番が逆に
なっていました。
つまり、COMP_TYPEの「補完のタイプに応じて補完関数が呼び出される」
という記述が先になり、その後に COMP_KEY の「現在の補完関数を呼び
出したキーです」が現れます。これなら、唐突さはありません。
man ページをまとめた方が、順番が逆になったこと対する気配りを
忘れたわけで、翻訳する側としては、これは仕方がないですね。
まあ、工夫の余地がないわけではありませんけれど。たとえば、
man ページも順番を逆にしてしまうとか。
>>> .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 のマニュアルですから、一般ユーザが
読むことを想定した方がよいのではないでしょうか。そう考えると、
日本語の「インデックス」に「文字列中の位置」の意味を持たせるのは、
ちょっと無理だと思います。一般ユーザにもプログラマーにも通用する
訳語を工夫するのは、翻訳者の腕の見せ所ですし。
もっとも、一般ユーザはこんな細かい変数の説明まで読むわけがないと
考えることもできますけれど。
>>> .B COMP_TYPE
>>> .\"O Set to an integer value corresponding to the type of completion attempted
>>> .\"O that caused a completion function to be called:
>>> .\"O \fITAB\fP, for normal completion,
>>> .\"O \fI?\fP, for listing completions after successive tabs,
>>> .\"O \fI!\fP, for listing alternatives on partial word completion,
>>> .\"O \fI@\fP, to list completions if the word is not unmodified,
>>> .\"O or
>>> .\"O \fI%\fP, for menu completion.
>>> .\"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).
>>> 補完関数を呼び出した補完のタイプに対応する整数値が設定されます。
>>> \fITAB\fP は通常の補完です。
>>> \fI?\fP は連続したタブ入力による候補のリスト表示です。
>>> \fI!\fP は途中まで補完した後の候補のリスト表示です。
>>> \fI@\fP は、途中での一致がないときの候補のリスト表示です。
>>> \fI%\fP はメニュー補完 (menu completion)です。
>>> この変数はプログラム補完機能 (後述の \fBプログラム補完\fP を参照)
>>> から呼ばれたシェル関数と外部コマンドにおいてのみ有効です。
>> to list completions if the word is not unmodified が、どうして
>> 「途中での一致がないときの候補のリスト表示です」になるのか、
>> わかりません。そもそも原文がわからないのです。
> 機能からいうと、'!' と '@' はそれぞれ、readline の変数の
> show-all-if-ambiguous と show-all-if-unmodified が On になって
> いるとき固有の補完の動作を表します。
>
> かなり長くなりますが、以下に実際の動作を示します。
詳しい説明ありがとうございます。ご説明を「Readline の変数」の
show-all-if-ambiguous や show-all-if-unmodified と合わせて読んで、
何故「途中での一致がないときの候補のリスト表示です」になるのか
わかったような気がします (「途中での」は「途中までの」のタイプミス
ですか)。
しかし、そうだとすると、これは原文が間違っているのでしょうか (not と
un のどちらかが不要)。それとも、「目下補完中の単語をユーザが
何か文字を打ち込むことによって変更しないでもない (変更する必要がある)
ときは」ということなんでしょうか。それでは、show-all-if-unmodified と
矛盾するだろうし ... いづれにしても、これは原文が意味不明瞭ですから
(わたしの読解力が足りないのかもしれませんが)、原文を離れ、実際の動作に
即してお訳しになったのも、当然だと思います。
>>> .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 の動作は以下のとおりです。
>
> $ echo $SECONDS
> 41
> $ echo $SECONDS
> 43
> $ echo $SECONDS
> 45
> $ unset SECONDS
> $ SECONDS=1
> $ echo $SECONDS
> 1
> $ echo $SECONDS
> 1
> $ echo $SECONDS
> 1
>
> 一度 unset したあとに値を設定すると、経過秒数を返す性質はなくなります。
説明をうかがえば、正しい訳だとわかりますが、「この変数の特殊な性格は
なくなります」という言い方は漠然としすぎていると思います。
こういうとき日本語では「bash に対する (とって) 特別な意味は (効果は、
働きは、関係は) なくなります (失われます)」などと言うのではないで
しょうか。つまり、「特殊な」か「特別な」か「特有の」か、「性質」か
「性格」か、あるいは properties をもっと具体的に表現した方がよいのか。
もうすこし訳語を練る余地があると思います。
>>> .B FUNCNAME
>>> .\"O An array variable containing the names of all shell functions
>>> .\"O currently in the execution call stack.
>>
>>> 現在実行している呼び出しスタックにある全てのシェル関数名が
>>> 入った配列変数です。
>>
>> 「現在実行している」はどこにかかるのでしょうか。それから、「現在」は
>> 「execution call stack に現在存在する」とかかるのだと思います (あれっ、
>> 「実行している」にかけても事実上同じことかな)。execution call stack の
>> 定訳があるなら、それを使うのが一番よいのですが。
>>
>> ちなみに、このマニュアル中では、execution call stack は「bash が
>> 実行している呼び出しスタック」(BASH_ARGC、BASH_ARGV)、「呼び出し
>> スタック」(caller) と訳されています。
>
> 「（現在の）呼び出しスタック」で統一しました。
execution call stack も、ただの call stack も同じだということですね。
「エクセキューション・コールスタック」とカタカナにする手もあると
思いますが、ちょっと長すぎるかもしれません。
>>> .\"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 から
かなり離れてしまいますが。
>>> .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 進数を代入し直します。
一例として前の訳をいじってみましたが、この方が具体的でしょう。
# それから、「1」の後ろに空白がありません。
>>> .B READLINE_POINT
>>> .\"O The position of the insertion point in the
>>> .\"O .B readline
>>> .\"O line buffer, for use with
>>> .B readline
>>> の編集バッファでのポイントの位置です。
>>
>> insertion の訳がありませんが、なくても同じことですか。
>
> はい。
インサーション・ポイント (挿入ポイント) なら、位置が限定されますが、
ポイントと言っただけでは、位置が限定されないのでないかと思うのですが。
>>> .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 が単に起動されることを
言っているのではないのだ、ということは伝わるでしょうから。
何かよい訳を思いつかれることを期待しています。
--
長南洋一