長南洋一
cyoic****@maple*****
2011年 1月 2日 (日) 10:25:56 JST
Fork長南です。
元木さんのメールより [JM:00090]
>
> > .\"O .SS OPTIONS
> > .\"O .P
> > .\"O All options always return true. Except for
> > .\"O .BR \-daystart ,
> > .\"O .B \-follow
> > .\"O and
> > .\"O .BR \-regextype ,
> > .\"O the options affect all tests, including tests specified
> > .\"O before the option. This is because the options are processed when the
> > .\"O command line is parsed, while the tests don't do anything until files
> > .\"O are examined. The
> > .\"O .BR \-daystart ,
> > .\"O .B \-follow
> > .\"O and
> > .\"O .B \-regextype
> > .\"O options are different in this respect, and have an effect only on tests which
> > .\"O appear later in the command line. Therefore, for clarity, it is best
> > .\"O to place them at the beginning of the expression. A warning is issued
> > .\"O if you don't do this.
> > .\"O
> > .SS オプション
> > .P
> > すべてのオプションは常に真を返す。
> > .BR \-daystart ,
> > .BR \-follow ,
> > .B \-regextype
> > を除いて、そのほかのオプションは、そのオプションより前に
> > 指定された判別式も含め、すべての判別式に影響を及ぼす。
> > これは、オプションの処理は、コマンドラインが解析されるときに
> > 行われるのに対して、判別式の方は、ファイルが調べられるまで
> > 何もしないからである。
> > .BR \-daystart ,
> > .BR \-follow ,
> > .B \-regextype
> > の各オプションはこの点で異なっている。この三つのオプションは、
> > コマンドラインで自分より後に指定された判別式にしか影響を
> > 及ぼさないのだ。従って、混乱を避けるためには、オプションを
> > 式の先頭部に置いた方がよい。そうしないと、警告が発せられる。
>
> 最後の文ですが、これら 3つのオプションを式の先頭部に置かなかった場合の
> 話なので、「そうしないと〜」というより「そうしなかった場合」とか
> 「先頭以外で指定した場合」とかの方が読みやすいかもしれません。
>
> また、「混乱を避けるためには、オプションを式の先頭部に置いた方がよい。」
> についてですが、「オプション」は実際には例外的な動作をする
> 3つのオプションのことなので、
> 「これらのオプションは式の先頭に置いた方がよい」のように、
> オプションを限定する表現はいかがでしょうか。
実験してみたのですが、findutils-4.4.2 の場合は、式の先頭に
置かないと、警告が発せられるのは、-daystart など三つの
オプションではなく、それ以外のオプションでした (4.4.0 では、
-regextype を先頭以外に置いたときも、警告が出ます)。
古いマニュアル (現行の翻訳の原文) を見ると、この部分は、
こんなふうになっていました。
All options always return true. They always take effect,
rather than being processed only when their place in the
expression is reached. Therefore, for clarity, it is best
to place them at the beginning of the expression.
つまり、新しいマニュアルの原文では、Therefore 以下の続き方が
おかしくなってしまったのです。そこで、わたしは、前の文に
付くような付かないような、曖昧なつなぎ方で、Therefore 以下を
つなげておきました。でも、わかりにくくなったことは確かなので、
やはり怠慢だったと思います。
きちんと訳すならば、to place them の them を「-daystar などを
含むオプション一般」と取るか、「-daystart などではない、一般の
オプション」と取るか、はっきりさせるべきでしょう。
前者のように取るなら (文法的にはこの方が自然ですが)、
以上のようなことから、混乱を避けるためには、オプションは一般に
式の先頭部に置いた方がよい。そうしないと、警告が発せられる。
後者のように取るなら (警告が発せられるのは、findutils-4.4.2 では
一般のオプションだけですから、こちらを選ぶべきかもしれません)、
従って、混乱を避けるためには、-daystart, -follow, -regextype
以外のオプションは、式の先頭部に置いた方がよい。そうしないと、
警告が発せられる。
こちらの方がよさそうですね。
それから、「そうしないと」より「そうしなかった場合」などの方が
よいのではないかというご意見ですが、「そうしないと」では仮定的な
感じが消えて、強くなりすぎるということですね。それはわかるの
ですが、「場合」を使わないですむところでは、できるだけ使いたく
ないという気持ちがあります。便利な言葉なので、つい、場合、場合と
繰り返しがちですから。
ついでですが、for clarity のよい訳はありませんか。
> > (訳注: なお、ちょっと変な表現になるが、
> > .BR \-amin ,
> > .BR \-cmin ,
> > .B \-mmin
> > のことも考えに入れると、「デフォルトでは時間を計算するときの基準を
> > 今現在に置くが、
> > .B \-daystart
> > を指定すると、時間計算の基準が今日の 24:00 になる」
> > と言えばよいのかもしれない。)
>
> 訳注の「ちょっと変な表現になるが」は不要かと思います。
>
> 訳注 : -amin, -cmin, -mmin のことも考慮に入れると、
> 時間計算の基準が 今現在から今日の 24:00 になる、と考えると
> 分かりやすいかもしれない。
>
> といった感じではいかがでしょうか。
「ちょっと変な表現になるが ... 言えばよいのかもしれない」は
わたしの自信のなさのあらわれです。
-daystart を指定した場合、時間計算の基準点が今日の 24:00 に
なるというのは、正しいのでしょうか。前のメールにも
書きましたが ([JM:00056])、私が実験したところでは、翌日の
00:01 が基準になっているような気がするのです。
「デフォルトでは云々」の部分は、atime などでデフォルトと
-daystart との違いを説明していないので、この訳注でそれを
はっきり言っておきたいと思います。
すこしくどいけれど、デフォルトの状態を強調するために、
「ちょっと変な表現になるが」だけ消して、元の文章をそのまま
残そうかと思います。「考えに入れると」は「考慮に入れると」
の方がよいですね。「と考えると、わかりやすいかもしれない」は、
どうしようか迷います。
> > .\"O .IP "\-help, \-\-help"
> > .\"O Print a summary of the command-line usage of
> > .\"O .B find
> > .\"O and exit.
> > .\"O
> > .IP "\-help, \-\-help"
> > .B find
> > のコマンドラインの使用法をざっと説明して終了する。
>
> 「使用法の概要を表示して終了する」くらいはいかがでしょうか。
find --help を実行して、おっしゃっていることがわかったような
気がしました。あれは「使用法の概要」とは言えても、「使用法を
ざっと説明する」とは言えないのではないか、ということですね。
でも、あれでも、ざっと説明しているつもりなんだと思います。たぶん。
わたしとしては、「find のコマンドラインの使用法の」と「の」が
三つも続くのがいやだったのです。ですから、「find の使用法の
概要を示して終了する」なら、抵抗感はありません。でも、強いて
command-line を省略することもないし、Print a summary を
「ざっと説明する」と訳しても間違いではないし、とも思います。
> > もし、調べるのがファイル名だけで充分なら、ファイルに対して stat 関数を
> ^^^^
> 「充分」→「十分」でしょうか
「充分」「十分」どちらの書き方もあるので、いつでも迷います。
使い分けの仕方って、あるのでしょうか。
> > .\"O Numeric arguments can be specified as
> > .\"O .IP \fI+n\fP
> > .\"O for greater than
> > .\"O .IR n ,
> > .\"O .IP \fI\-n\fP
> > .\"O for less than
> > .\"O .IR n ,
> > .\"O .IP \fIn\fP
> > .\"O for exactly
> > .\"O .IR n .
> > .\"O .P
> > .\"O
> > 数値の引き数は、以下の形で指定することができる。
> > .IP \fI+n\fP
> > .I n
> > を越える数であることを意味する。
>
> 「n より大きい数」などはどうでしょうか。
次の項目で曖昧さのない「未満」を使いたかったので、こうしました。
ここで「より大きい」を使うと、次の項目で「より小さい」を
使うことになりますから。
> > .\"O .IP
> > .\"O The response to the prompt is matched against a pair of regular
> > .\"O expressions to determine if it is an affirmative or negative
> > .\"O response. This regular expression is obtained from the system if the
> > .\"O `POSIXLY_CORRECT' environment variable is set, or otherwise from
> > .\"O .BR find 's
> > .\"O message translations. If the system has no suitable
> > .\"O definition,
> > .\"O .BR find 's
> > .\"O own definition will be used. In either case, the interpretation of
> > .\"O the regular expression itself will be affected by the environment
> > .\"O variables 'LC_CTYPE' (character classes) and 'LC_COLLATE' (character
> > .\"O ranges and equivalence classes).
> > .\"O
> > .\"O
> > .\"O
> > .IP
> > プロンプトに対する応答は、肯定・否定を表す一組の正規表現と突き合わせて、
> > 同意か、不同意かが判断される。
>
> 日本語だけ読んでいると、なかなか難解でした。
>
> 原文もそうなのですが、「プロンプト」はここで初めて登場するので、
> ユーザに対する問い合わせとの関係が分かるといいかなと思いました。
> 「プロンプトに対するユーザの応答は〜」などはいかがでしょうか。
「ユーザの」を入れた方がよいですね。
> 「肯定・否定を表す一組の正規表現と突き合わせて、」の
> 「突き合わせて」ですが、「照合され」はいかがでしょうか。
「突き合わせて」は against の強さに引っ張られたんだと思います。
全体に文章が固いので、「に照らして」か「と照らし合わせて」
くらいにやわらげた方がよいかもしれません。
> > この正規表現は、環境変数 `POSIXLY_CORRECT' が
> > 設定されていれば、システムから得られるが、設定されていない場合は、
> > .B find
> > のメッセージ・トランスレーションから取得される。システムに
>
> 「POSIXLY_CORRECT が設定されている場合はシステムから取得され」
> のように、その直後の文と韻を合わせると読みやすいと思いますが、
> いかがでしょうか。
「いれば、 ... 場合は、」は、どちらかにそろえましょう。
「得られるが ... 取得される」の言い換えの方は、そのままでよい
のではないかと思います。同じ言葉を使った方が、論理がたどりやすい、
言い換えた方が耳あたりがよいという「あちら立てれば関係」ですから。
> 「メッセージ・トランスレーション」はそれほど一般的な用語ではないと
> 思いますが、訳もなかなか難しいですね。強いて訳すとしたら、
> 「find が持つメッセージ翻訳データベースから取得される」くらいかなぁ。
これは質問するつもりで忘れていたのでした。おっしゃるとおり、
「メッセージ・トランスレーション」という訳は (訳じゃないですね)、
強引だと思います。「標準への準拠」セクションにこんな表現があります。
.\"O .IP \fB\-ok\fR
.\"O Supported.
.\"O Interpretation of the response is according to the "yes" and "no"
.\"O patterns selected by setting the `LC_MESSAGES' environment variable.
.\"O When the `POSIXLY_CORRECT' environment variable is set, these patterns
.\"O are taken system's definition of a positive (yes) or negative (no)
.\"O response. See the system's
.\"O documentation for \fBnl_langinfo\fP(3), in particular YESEXPR and
.\"O NOEXPR. When `POSIXLY_CORRECT' is not set, the patterns are instead
.\"O taken from
.\"O .BR find 's
.\"O own message catalogue.
同じことのようですから、この message catalogue を使いましょうか。
「メッセージカタログ」でも、何のことかよくわからないと言われれば、
そうなんですけれど。
> > .\"O .IP "\-printf \fIformat\fR"
> > .\"O True; print \fIformat\fR on the standard output, interpreting `\e'
> > .\"O escapes and `%' directives. Field widths and precisions can be
> > .\"O specified as with the `printf' C function. Please note that many of
> > .\"O the fields are printed as %s rather than %d, and this may mean that
> > .\"O flags don't work as you might expect. This also means that the `\-'
> > .\"O flag does work (it forces fields to be left-aligned). Unlike
> > .\"O .BR \-print ,
> > .\"O .B \-printf
> > .\"O does not add a newline at the end of the string. The escapes
> > .\"O and directives are:
> > .IP "\-printf \fIformat\fR"
> > 真を返す。標準出力に \fIformat\fR を出力する。そのとき `\e' を
> > エスケープ文字の、`%' を書式指定子の始めとして解釈する。
>
> 申し訳ありませんが、この文もちょっと読み辛かったです。
>
> '\e' はエスケープ文字として、'%' は書式指定子として解釈される、
>
> などでもよいのではないでしょうか？
>
> 厳密には長南さんの訳のように「〜の始め」の方が正確かもしれませんが、
> バックスラッシュをエスケープ文字と呼ぶのは比較的一般的だと思います。
いえ、いえ、申し訳ないなんてことはありません。読みにくい箇所の
ご指摘はとてもありがたいことです。うまく書き直せるかどうかは、
わかりませんけれど。
「読み辛い」というのは、違和感があるということですか。
この部分については、私の反応は、元木さんの反対でした。
つまり、原文に違和感をおぼえたのです。
たとえば、LANG=C man bash によれば、
A non-quoted backslash (\) is the escape character.
---- (中略) ----
... with backslash-escaped characters replaced as specified
by the ANSI C standard. Backslash escape sequences, if present,
are decoded as follows:
\a alert (bell)
\b backspace
\e an escape character
確かに、ここでは、エスケープ文字とは \ のことで、\a などは
バックスラッシュでエスケープされた文字、あるいは、バック
スラッシュエスケープシーケンスと呼ばれています。
わたしが \ を「バックスラッシュの始め」と訳したことに、
元木さんが違和感を持たれても、当然だと思います。
しかし、find.1 の原文はこうです。
... interpreting '\' escapes and '%' directives. (中略)
The escapes and directives are:
\a Alarm bell.
\b Backspace.
こちらでは、escapes は、\a や \b のことを指しています。
それで、\a などを「エスケープ文字」と訳したら、 \ をエスケープ
文字とは言えなくなってしまいます。% についても同様です。
はっきり言って、原文の言葉遣いが不用意なのです。ですから、
翻訳側としては、行き方が二つあると思います。
ひとつは、わたしのように訳す行き方。「\ をエスケープ文字の始め
として解釈する」に違和感がありすぎるのなら、
\ をエスケープ文字の指標 (あるいは、印) として解釈する
とか、
\ で始まる文字を (に続く文字を) エスケープ文字として解釈する
と翻訳するわけです。文字と文字列を区別するなら (この場合、
\a などを文字列と言ってよいかという疑問はありますが)、
\ で始まる文字列をエスケープ文字列として解釈する
もう一つは、escapes に「エスケープ文字」以外の訳語を当てること。
しかし、こちらを採用した場合、escapes についてはよいとしても、
derectives の方をどう扱うかという問題が残ってしまいます。
% とそれに続く文字を合わせて書式指定子なのであって、% そのものが
書式指定子なのではありませんから。
> > フィールドの幅や精度は、C 言語の `printf' 関数と同じやり方で
> > 指定できる。フィールドの多くは、%d ではなく、%s として
> > 出力されることに注意していただきたい。すなわち、フラグが期待通りに
> > 効かないかもしれないのだ。だが、それはまた、`\-' フラグが
> > 使えるということでもある (フィールドを強制的に左揃えにする)。
>
> 括弧内は '\-' フラグの直後に置いた方が読みやすいと思いました。
ここは、直しておきます。
> > .\"O A `%' character followed by any other character is discarded, but the
> > .\"O other character is printed (don't rely on this, as further format
> > .\"O characters may be introduced). A `%' at the end of the format
> > .\"O argument causes undefined behaviour since there is no following
> > .\"O character. In some locales, it may hide your door keys, while in
> > .\"O others it may remove the final page from the novel you are reading.
> > .\"O
> > 一個の `%' に上記以外の文字が続く場合、`%' 文字は捨てられるが、
> > それに続く文字は表示される (書式指定文字が新たに追加されるかもしれないので、
> > この動作を当てにしてはいけない)。書式指定の末尾に `%' があるときの動作は、
> > 続く文字がないので不定である。あるロケールでは、お宅のドアの鍵が
> > 見つからなくなるかもしれない。また、別のロケールでは、
> > お読みの小説の最後のページが消えてしまうかもしれない。
>
> これはユーモアの部分なので、(私も得意ではないのですが)
>
> ひょっとすると、ロケールによっては、家のドアの鍵が見つからなくなったり、
> お読みの小説の最後のページが消えてしまったりするかもしれませんよ。
>
> といった感じでしょうか。
おっしゃっていることがわかりませんでした。それでも、考えて
いる内に、読者との距離のとり方を指摘していらっしゃるのでは
ないか、と思えてきました。読者に語りかける調子を選ぶのなら、
ここだけ「です、ます」を混ぜた方がよい。その方が、ジョークが利く。
インパーソナルな感じで通すのなら、「お宅の」や「お読みの」が
中途半端だ。そういうことですか。
# 別な言い方をすると、you (your) の訳し方の問題。
# 著者が you を使ったときは、たいてい読者との距離を意識して
# いるのだと思います (you が「人は」の意味の場合でも)。
# そして、その距離を翻訳でどう出すかは、翻訳者の裁量と工夫。
「です、ます」は元木さんが訳例を上げてくださったので、
インパーソナルな方をやってみます (真面目な顔で冗談を言うというやつ)。
書式指定の末尾に % がある時の動作は、続く文字がないので不定である。
ロケールによっては、ドアの鍵が見つからなくなるかもしれない。
また、別のロケールでは、読みかけの小説の最後のページが消えて
しまうかもしれない。
うーん、「です、ます」、インパーソナル、中間、どれもあるような。
で、わたしは中間を選んだわけですけれど。
--
長南洋一