[JM:00092] Re: [POST:RO] GNU_findutils find.1

Back to archive index

長南洋一 cyoic****@maple*****
2011年 1月 2日 (日) 10:25:27 JST


長南です。

みなさん、あけましておめでとうございます。
元木さんの三つ目のご意見を楽しみしております。ちょっと
びくびくしながらも。

さて、
日本語としてわかりやすいか、読みやすいかまでチェックして
くださったのですね。ありがとうございます。長いマニュアルなので、
チェックも大変だったことでしょう。できるだけ、ご意見を生かし
たいと思います。そう言いながら、反論ばかり書くのですが。

元木さんのメールより [JM:00089]
> 
> > .\"O This manual page talks about `options' within the expression list.
> > .\"O These options control the behaviour of 
> > .\"O .B find
> > .\"O but are specified immediately after the last path name.  The five
> > .\"O `real' options
> > .\"O .BR \-H , 
> > .\"O .BR \-L , 
> > .\"O .BR \-P , 
> > .\"O .B  \-D 
> > .\"O and 
> > .\"O .B  \-O
> > .\"O must appear before
> > .\"O the first path name, if at all.  A double dash 
> > .\"O .B \-\-
> > .\"O can also be used
> > .\"O to signal that any remaining arguments are not options (though
> > .\"O ensuring that all start points begin with either `./' or `/' is
> > .\"O generally safer if you use wildcards in the list of start points).
> > このマニュアルページで説明する「オプション」には、式の一部として
> > 使われるものもある。そうしたオプションは、
> > .B find
> > の動作を制御するものであり、指定する位置は最後のパス名の直後になる。
> > これに対して、
> > .BR \-H ,
> > .BR \-L ,
> > .BR \-P ,
> > .BR \-D ,
> > .B  \-O
> > という五つの「本来」のオプションは、指定するなら、最初のパス名の前で
> 
> 個人的には、「指定するなら」ですが、「指定する場合には」などの方が
> 条件の意味合いが理解しやすいように感じました。

「指定するなら」は if at all の訳ですが、確かに、「これに
対して、-H, -L,-P, -D, -O という五つの『本来』のオプションを
指定する場合は」と訳すのもよいと思います。ただ、たぶん、
わたしは、「そうしたオプションは ...」、「『本来』のオプションは
...」と、主語を (というか主題を) そろえたかったのだと思います。

# 「These options control the behaviour of find but are  specified
# immediately after the last path name.」の but をあえて and として
# 訳しましたが、正しかったかどうか。-L や -H も find の動作を
# 制御するわけですから、述語のオプションの方は、「find の動作を
# 細かく制御するものだが」と補充して訳した方がよいかもしれません。

> > 指定しなければならない。なお、ダッシュを二個重ねた
> > .B \-\-
> > も、以下の引き数はオプションではないことを明示する印として使用することが
> 
> 「-- も」以降の部分で、「も」は also から来ていると思いますが、
> 日本語だと「〜も」は同様のものを続けるときに使うので、
> 少しニュアンスが違うように感じました。
> この also は「また〜である」くらいの意味のように思いました。
> 
> また、「以下の引き数」は「以降の引き数」とするのはいかがでしょうか。
> 
> 訳としては、
> 
>   また、以降の引き数がオプションではないことを明示する印として、
>   ダッシュを二個重ねた -- を使用することができる。
> 
> とか
> 
>   また、ダッシュを二個重ねた -- は、それ以降の引き数がオプション
>   ではないことを明示するオプションである。
> 
> などを考えてみました。いかがでしょうか。

わたしは、「A  double dash -- can also」以下を但し書きと取って、
「なお」と始めたのだと思います。元木さんの「また、以降の引き数が
……」の「また」も、但し書きというか、補足の始まりですね。

also については、「-H など五つの本来のオプションのほかに、
GNU の標準オプションである -- もまた使える」ということだと
考えました。

なお、「以下」はわたしの書き癖ですが、確かに引き数が下に続く
わけではないので、不適当かもしれません。「後続」か「後に続く」は
どうでしょう。いっそ、「も」を後ろの方に移して、こななふうに
しましょうか。

  なお、ダッシュを二個重ねた -- を使用して、後に続く引き数が
  オプションではないことを明示することも可能である。

あれっ、「こと」が二個続いてしまった。「オプションではないと
明示する」もありますが、「オプションではないことを明示する」の
方がはっきりしているし、迷うところです。

> > .\"O .IP
> > .\"O When the 
> > .\"O .B \-L 
> > .\"O option is in effect, the 
> > .\"O .B \-type 
> > .\"O predicate will always
> > .\"O match against the type of the file that a symbolic link points to
> > .\"O rather than the link itself (unless the symbolic link is broken).

> > .B \-L
> > オプションが有効だと、述語
> > .B \-type
> > は (訳注: 「述語 predicate」とは、式を構成するオプション、判別式、
> > アクションなどの基本語彙を言う)、リンクそのものに対してではなく、
> > 常にシンボリックリンクが指しているファイルのタイプに対してマッチを
> > 行うようになる(シンボリックリンクがリンク切れしている場合を除く)。

> 「述語 predicate」の記載ですが、括弧が重なっても
> 「述語 (predicate)」の方が読みやすいように感じましたが、
> いかがでしょうか。

(訳注: 「述語 (predicate)」とは ...) にするわけですね。そう
しましょうか。

> > GNU
> > .B find
> > は実際の探索に取りかかる前にコマンドラインの処理を行うが、
> > その際 stat システムコールを使ってファイルの情報を調べることが
> > よくある。上述のオプションは、そのとき引き数がどう処理されるかにも
> > 影響を与える。具体的に説明しよう。いくつのの判別式では、
> > コマンドラインで指定したファイルを目下検査の対照になっているファイルと
>                                               ^^^^
> 「対照」→「対象」

直しておきます。

> > 照合する。いづれの判別式でも、コマンドラインで指定したファイルは、
> 
> どちらでもいいのですが、「いづれ」は歴史的な仮名遣いですね。

いづれどなたかがお気づきになるだろうと思っていました。
「いずれ」は、現代仮名遣いが不見識というか、無原則であることの
一例だと思っています。発音どおりの表記を原則として、表記法が
複数ある場合は、言葉の成り立ちや語源を考慮するのならば、
「いづれ」は、「いづこ、いつ、いかに」などの同族でしょうから、
「いづれ」と書くべきだと思います。「づ」は「わたつみ」や
「あまつ乙女」の「つ」なんじゃないでしょうか。

「何れ」は当て字だし、「孰れ」は気取りすぎだし。

> > .\"O .IP stat
> > .\"O Print messages as files are examined with the 
> > .\"O .B stat 
> > .\"O and 
> > .\"O .B lstat 
> > .\"O system calls.  The 
> > .\"O .B find
> > .\"O program tries to minimise such calls.
> > .IP stat
> > .B stat
> > や
> > .B lstat
> > システムコールを使ってファイルが調べられたとき、
> > メッセージを表示する。
> > .B find
> > プログラムは、そうしたシステムコールの回数を最少にしようとする。
>                                               ^^^^
> 最少 → 最小、でしょうか。

「少ない回数」だから、「回数は最少」じゃないんですか。
でも「最小公倍数」とか「小さい数」とも言いますね。
わからなくなってきました。

> > .\"O The findutils test suite runs all the tests on 
> > .\"O .B find
> > .\"O at each optimisation level and ensures that the result is the same.
> > .\"O .P

> > なお、findutils のソースに付属する一連のテストは、各最適化レベルの
> > .B find
> > ですべての判別式を実行して、結果が同じになることを保証している。
> 
> この部分ですが、すべての「判別式」ではなく、すべての「テスト」では
> ないでしょうか。ここでいうテストは、find の動作で書かれている "test(s)"
> ではなく、find の動作を検証するため、test set の方ではないでしょうか。
> 
> 最適化レベルをどれにしても同じ動作になることを保証しようとしているので、
> 個別の判別式の動作を検証するだけではなく、評価順序が最適化レベルに
> 応じて変化するような場合についても「テスト」する必要がありますので。
> 
> 「全ての最適化レベルで全てのテストを行い」くらいでしょうか。

白方さんと同じご意見で、「テストスイートはそのすべてのテストを
実行して ……」という解釈ですね。

うーん、お二人に言われて、だんだんそんな気がしてきました。
ただ、決め手となる根拠がもうひとつ足りない気もします。
findutils のソースに付属する findutils-4.4.2/{find,xargs,locate}/
testsuite 以下を調べればよいのかもしれませんが、わたしには
見てもわかりませんでしたし。

それから、all the test をテストスイートのテストと取った場合、
The findutils test suite はどう訳したらよいのでしょうか。

「テストスイート」をそのまま使うことはできないでしょう。
「findutils のソースに付属する一連のテストは、そのすべての
テストを」とか、「findutils のソースに付属するテスト一式は、
そのすべてのテストを」というのも、何だか変です。
「一連のテスト」や「テスト一式」という言葉が、その要素である
テストのすべてを連想させてしまうため、同義語の反復のように
なるのが気になるのです。まあ、「テスト一式」はぎりぎり大丈夫
かもしれません。テストの集合に対して、それが複数の要素から
なることよりも、一つの単位であることの方に焦点を当てる言葉が
あればよいのですけれど。「テスト集」というのを思いつきましたが、
ほかにはないでしょうか。

と書いた後で、また findutils のソースパッケージを見直して
みました。findutils-4.4.2/doc/find-maint.info という文書に
こんなくだりがあります。

  4.1 Make the Compiler Find the Bugs

  Finding bugs is tedious.  If I have a filesystem containing
  two million files, and a find command line should print one
  million of them, but in fact it misses out 1%, you can tell
  the program is printing the wrong result only if you know
  the right answer for that filesystem at that time.  If you
  don't know this, you may just not find out about that bug.
  For this reason it is important to have a comprehensive test suite.

    The test suite is of course not the only way to find the bugs.
  (以下省略)

テストスイートはバグチェックをやっているんですね。そのバグ
チェックの一部として、どの最適化レベルでも結果が変わらないことの
チェックがあるらしい。そう理解すると、

  なお、findutils のソースに付属するテスト集では、そのすべての
  テストを各最適化レベルの find で実行して、(どの最適化レベル
  でも) 結果が同じであることを保証している。

うーん、ちょっと違和感があります。チェックによっては、すべての
最適化レベルでやる必要がないものもあるかもしれませんし、テストの
すべてを実行するのは、結果が同じであることを保証するのが目的では
ありませんし。もっとも、この部分はおまけみたいな記述ですから、
細かいことは気にしないでもよいのかもしれません。

-- 
長南洋一




linuxjm-discuss メーリングリストの案内
Back to archive index