長南洋一
cyoic****@maple*****
2011年 10月 14日 (金) 23:07:14 JST
長南です。 有難うございます。どう返事をしようかと、考えあぐんでいるところ でしたから、とても助かりました。 元木さんのメールより [JM:00448] > > >>>> .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 の訳ですと言えないこともありませんし。 >>>> .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 しても元には戻りません。 >>> 説明をうかがえば、正しい訳だとわかりますが、「この変数の特殊な性格は >>> なくなります」という言い方は漠然としすぎていると思います。 >>> こういうとき日本語では「bash に対する (とって) 特別な意味は (効果は、 >>> 働きは、関係は) なくなります (失われます)」などと言うのではないで >>> しょうか。つまり、「特殊な」か「特別な」か「特有の」か、「性質」か >>> 「性格」か、あるいは properties をもっと具体的に表現した方がよいのか。 >>> もうすこし訳語を練る余地があると思います。 >> >> 通常の（special ではない）変数と対比して「特殊」という意味だと思い、い >> ろいろ考えると「special」を「特殊」と訳すのが自然かと思いました。 >> 「固有」という訳も考えましたが、「固有」だと「通常の（special ではな >> い）変数」との対比ではなく、それぞれの変数が違うニュンアンスになってし >> まうように感じました。 > > 長南さんが気にされているのは、special の訳と、properties の訳の両方ですね。 > > properties の方ですが、 > 日本語で「性質」というと、化学物質等の振る舞いを連想させることが多く、 > 変数の「性質」というのはあまり言わない表現だと思います。 > どちらかというと、変数が持つ「役割」とか「意味」の方がしっくり来る気がします。 > > special の方は、「特別な」か「特殊な」あたりかなと思います。 > > 全体としては「変数が持つ特別な役割がなくなります」を推しておきます。 > 特別→特殊、役割→意味 に置き換えても誤解は生まないと思います。 ええ、property の訳は、とても難しいと思います。「性質」や「性格」で すむときはよいのですが、property の概念と「性質、性格」の概念は かなり違っていて、property の概念には「性質」や「性格」の概念に 存在しないものが含まれている。たとえば、あるものが他のものに 対して持っている役割とか、意味とか、関係とか。ファイルならそれが 作成された時間とか、所有者とか。「属性」の方が意味が近いでしょうが、 これもぴったり一致するわけではありませんし。 そんなわけで、わたしなど、困ったときは「プロパティ」とカタカナにして すませてしまいますが、この場合のように、その手が使えないときもある わけです。そういうときは、ほんとうに難しい。その場合における property の具体的な意味を考えて、訳語を工夫するよりないだろうと思います。 この場合なら、SECONDS を例に取れば、bash が稼働秒数を代入し続ける という特性を SECONDS という変数は持っている。COMP_WORDBREAKS ならば、 単語補完のときに readline ライブラリが、区切り文字として使用する 文字群を保持するという特性を持っている。そして、unset すると、bash に 対するそうした特別な関係がなくなってしまう。ほかの変数のことも考えに 入れると、やっぱり、「役割」か「意味」というところでしょうか。 「関係」もありそうです。 ただ、わたしとしては、「この変数が bash に対して持つ特別な役割」 と「bash に対して持つ」を補足した方がよいと思います。 >>> .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 >>> の各要素に対応し、呼び出しスタックを表します。 >> 手元の英和辞典いくつかに「表現する」という訳語があったため、 >> 「表現します」と変更しました。 > 各要素は呼び出しスタックの各要素に対応しているのであり、 > 呼び出しスタック(全体)を表現しているわけではないですね。 ええ、そういう意味で、「FUNCNAME の各要素は ... 呼び出しスタックを 表します」はアウトですが、「FUNCNAME の各要素は ... 呼び出しスタックを 表現しています」は、ぎりぎりセーフだと思います。当たらずと言えど、 遠からずで。 でも、いづれにしろ、辞書にある訳語がどれもこの場合ぴったりして いないわけですから、こういう場合には、自分で訳語を工夫する必要が あると、わたしとしては言いたかったわけです。そして、わたしの試訳は、 その一例だと。 # たぶん、自分で訳語を工夫するには、しっかりした英英辞典に当たって、 # 問題の言葉の中心的な意味を押さえ、さらに、英語の文例や和訳例も # 調べてみる必要があるでしょう。 # 訳例を調べるには、「英辞郎」がとても役に立ちます。 # http://www.alc.co.jp/ > なかなか難しいですが、describe のニュアンスを出しながら、意訳してみました。 > > FUNCNAME の各要素には BASH_LINENO と BASH_SOURCE に対応する要素があり、 > これらを参照することで、呼び出しスタックの状態を確認できます。 これも一つの工夫ですね。 >>>> .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 進数に置き換わります。 もあると思います。「シェルは ... この変数に」と主語と対象を出した方が 明晰でしょうけれど。 >>> .B SHLVL >>> .\"O Incremented by one each time an instance of >>> .\"O .B bash >>> .\"O is started. >>> .B bash >>> の実体が起動されるたびに 1 ずつ増えます。 >> 少し意訳が入りますが、“何に対して増えるのか”が誤解のもとのようなので、 >> 以下のように変更しました。 >> >> bash が起動するときに、環境変数で渡された値から 1 増やした値が >> 設定されます。 > > 別メールでもコメント致しましたが、 > 個人的には、この表現は誤解も少なく、いい意訳かなと思います。 たしかに正確ですね。でも、元木さんが [JM:00446] でお示しになった 「サブプロセスとして bash が起動されると、SHLVL が増える」という 考え方も、簡潔で捨てがたいと思います。その行き方なら、「サブプロセス として bash が起動されるたびに、1 すつ増えます」でしょうか。 -- 長南洋一
Fork