長南洋一
cyoic****@maple*****
2013年 10月 10日 (木) 22:01:57 JST
長南です。 かなり間が空いてしまいましたが、気を取り直して。 元木さんのメールより [JM:00929] > >> 5.2 `tail' >> >> `-f' >> `--follow[=HOW]' >> ---- (省略) ---- >> There are two ways to specify how you'd like to track files with >> this option, but that difference is noticeable only when a >> followed file is removed or renamed. If you'd like to continue to >> track the end of a growing file even after it has been unlinked, >> use `--follow=descriptor'. ... ^^^^^^^^ >> >> このオプションを使ってファイルの追跡をするとき、二つの方法が選択 >> できるが、その違いがわかるのは、追いかけているファイルが消去され >> たり、名前を変更されたりしたときだけである。もし、増大しつつある >> ファイルがアンリンク (unlink) されたあとでも、そのファイルの末尾の >> 追跡を続行したいならば、`--follow=descriptor' を使用すればよい。 >> この unlinked なんですが、removed という言葉も使われています。両者を >> 同じ意味と取ってよいのか、つまり、unlinked を「削除される」と訳して >> よいのか。それとも、unlink は「アンリンク」のままにしておくべきなのか。 >> 目下のところ、「消去/削除」にしてしまいたい気持ちが強くなっています。 >> でも、それなら、何で unlink という言葉を使っているのでしょう。 > > 訳としては「削除」でいいと思います。 > > きちんと理解するにはファイルシステムに関する理解が必要だと思いますが、 > ざっくり言うと、ファイルがファイルシステムから本当に削除されるのは、 > ファイルシステムからそのファイルが切り離され（ディレクトリからの参照が > なくなり）、ファイルが使用されなくなった（ファイルがクローズされるなど） > ときです。前者を unlink と言っています。 > > 通常はオープンされていないファイルを削除するので、 > rm コマンドを行うと unlink が呼ばれ、ファイルが削除されます。 > システムコールは unlink(2) です。remove(2) はありません。 > > この場合は tail がオープンしているので、unlink してもファイルはまだ存在 > します。 ディレクトリエントリからファイルの名前を消すことと、そのファイルが 本当に使用できなくなることを区別して、前者を unlink と言っている ということですね。文章としては、「削除」で一応通るけれど、厳密に言うと 違う。微妙ですね。「削除 (unlink)」とする手もありますけれど。 >> 5.4 `csplit' >> >> `-b SUFFIX' >> `--suffix=SUFFIX' >> Use SUFFIX as the output file name suffix. When this option is >> specified, the suffix string must include exactly one >> `printf(3)'-style conversion specification, possibly including >> format specification flags, a field width, a precision ... >> SUFFIX を出力ファイル名の接尾辞として使用する。このオプションを >> 指定する場合、接尾辞として指定する文字列は、`printf(3)' 方式の >> 変換指定をただ 1 個含むものでなければならない。形式指定フラグ、 > > 変換指定がただひとつだけ入ったものでなければならない、 > の方が個人的には読みやすいです。 その方がよいですね。いただきます。もうちょっといじるかもしれませんけれど。 動作に即して厳密に言うと、「`printf(3)' 方式の変換指定を必ず 1 個は 含まなければならない。また 1 個しか含んではいけない」ということ なので (たとえば、-b '%d.txt' といった指定が可能)、そのへんをどう 出すか考えてしまいます。 >> `-z' >> `--elide-empty-files' >> Suppress the generation of zero-length output files. (In cases >> where the section delimiters of the input file are supposed to >> mark the first lines of each of the sections, the first output >> file will generally be a zero-length file unless you use this >> option.) The output file sequence numbers always run >> consecutively starting from 0, even when this option is specified. >> >> サイズ 0 の出力ファイルができないようにする (入力ファイルを部分に >> 区切る行が、各部分の最初の行でもある。そういう想定の場合に、この >> オプションを使わないと、一番目の出力ファイルがたいていサイズ 0 に >> なる)。このオプションが指定されているときでも、出力ファイルの >> 連続番号が 0 から始まって、順番に増えていくことに変わりはない。 > > この部分が少し曖昧だったのですが、ここで言いたいのは、 > サイズ 0 のファイルを作成しない場合であっても、 > 番号がずれるわけではない、ということでしょうか？ > 言い換えると、作成されなかったファイルは欠番になる、ということ？ > それとも、番号が詰められるのでしょうか。 少し前にある文章「デフォルトの接尾辞は、二桁の 10 進数を `00' から `99' まで順番に増やして行ったものである」に呼応しています。ですから、 -z の使用、不使用にかかわらず、デフォルトでは、ファイル名は xx00, xx01, xx02 ... となります。 >> "In cases ..." の "are supposed to" がうまく訳せないでいます。 > > 入力ファイルの区切り行が各部分の最初の行のような場合には、 > 最初の出力ファイルはサイズが 0 のファイルとなる。 > > くらいでどうでしょうか。 意味が伝わりさえすれば、"are supposed to" にこだわらなくてもよいかも しれませんね。ただ、原文は、実行者が「区切り行を同時に各部分の最初の 行にする」という意図を持っていることを強調したいのだと思います。 考えてみれば、二番目以降の出力ファイルでは、当然ながら、区切り行が 必ず最初の行になるわけですから、一番目のファイルでもそうしたい場合 ということにすぎません。 入力ファイルを部分に区切る行が、どの部分においてもその最初の行に なることになっている場合に 素直に訳してみたのですが、「なることになる」がちょっとたどたどしい。 それなら、「... なることを想定している場合に」。 あるいは、"the section delimiters of the input file" を原文どおり、 行ではなくデリミタ (具体的には、文字列) として、 入力ファイルを部分に区切る文字列が各部分の最初の行に現れるように する場合に いっそのこと、 入力ファイルを部分に区切る行を、どの部分でもその最初の行にする場合に でも充分かもしれません。 >> 6.4 `md5sum' >> >> Note: The MD5 digest is more reliable than a simple CRC (provided by >> the `cksum' command) for detecting accidental file corruption, as the >> chances of accidentally having two files with identical MD5 are >> vanishingly small. However, it should not be considered secure against >> malicious tampering: although finding a file with a given MD5 >> fingerprint is considered infeasible at the moment, it is known how to >> modify certain files, including digital certificates, so that they >> appear valid when signed with an MD5 digest. For more secure hashes, >> consider using SHA-2. *Note sha2 utilities::. >> >> 注意: MD5 ダイジェストは、ファイルの不測の損傷を検知することに >> 関して、単純な CRC (`cksum' コマンドで使用できる) よりも信頼性が高い。 > > 「検知に関して」の方が読みやすいです。 「ファイルの不測の損傷の検知について」と「の」を三つ続けたくなかった のです。「MD5 ダイジェストは、」の読点を取れば、このままでも少し読み やすくなるのではないでしょうか。 # ほかのメールでご指摘なさっていますが、わたしの文章に読点が多いのは、 # 自分でも気がついています。原則として、節などの意味の切れ目に読点を # 入れていますが、「が」や「は」の前に少し長い句が来ると、つい点を # 打ってしまいます。「もし、」や「でも、」も同じで、そうしないと # どうも落ち着かないのです。 >> 二つのファイルがたまたま同一の MD5 値を持っている確率は、ほとんどゼロ >> だからである。だからと言って、悪意のある改竄に対して安全だと考えては >> ならない。ある特定の MD5 指紋を持つファイルを見つけ出すことは、現在の >> ところ事実上不可能だと考えられているが、デジタル証明書を含むある種の >> ファイルが署名に MD5 ダイジェストを使用しているとき、そうしたファイル >> に手を加えて、有効に見えるようする方法なら、周知のことだからである。 >> もっと安全なハッシュ値が必要なら、SHA-2 の使用を考慮した方がよい。 >> >> "it is known how to modify certain files" 以下が具体的にどういうことか、 >> よくわかっていません。そんなわけで、訳に自信がありません。 > 意味としては、MD5 ダイジェストでの署名では正当に見えるようにしたまま > 特定のファイルを変更する方法が知られている、ということです。 ja.wikipedia.org の md5sum の項なども見てみたのですが、やっぱりわかり ません。これは、要するに MD5 の脆弱性を言っているのでしょう。でも、 「ある特定の MD5 指紋を持つファイルを見つけ出す」、つまり、あるファイル の MD5 値と同じ MD5 値を持つ別のファイルを見つけ出すことと、(元木さんの まとめ方を借用するなら) 「MD5 ダイジェストでの署名では正当に見えるように したまま特定のファイルを変更する」こととの違いがわかりません。署名という のは、要するにデータのハッシュ値を署名者の秘密鍵で暗号化したものなので しょう。ここで暗号 (復号) 化に問題がないとすれば、「署名が正当に見える」 ということは、ハッシュ値が (この場合 MD5 値が) 正当に見えるということ ではないでしょうか。ということは、改変されたデータが元のデータと同じ MD5 値を持っていることになりませんか。つまり、あるファイルの MD5 値と 同じ MD5 値を持つ別のファイルが作れるということになり、"finding a file with a given MD5 fingerprint is considered infeasible" と矛盾するのでは ないでしょうか。矛盾するというよりも、二つの状態の違いを原文がうまく 説明し切れていないのではないか、という気もしますけれど。 このようにさっぱりわかっていないので、この部分はわたしの手に負えません。 訳文が大体通用するようならよいのですが、そうでないならば、適切な案を 教えていただけると、ありがたいと思います。 なお、valid は「有効、正当、正規のもの」などを考えました。、どれもイマイチ ピッタリしないと思っていたのですが、「有効」より「正当」の方がよいですか。 -- 長南洋一
Fork