長南洋一
cyoic****@maple*****
2013年 9月 27日 (金) 19:38:09 JST
Fork長南です。
たくさんチェックしてくださって、ありがとうございます。
ほとんど全文引用になってしまいました。読みにくいでしょうが、ご容赦
ください。
元木さんのメールより [JM:00928]
>
>> 10.1 `ls'
>> 10.1.2 表示する情報
>>
>> `-D'
>> `--dired'
>>
>> これは全体に難解なのですが、以下の applications がわかりません。
>> 一般ユーザにも使えるようにしたシェルスクリプトのことを言っているのか。
>> それとも、一般的な「応用」と取って、「`--dired' を使用する作業では」
>> ぐらいに訳しておいた方がよいのか。後者と取ると、「ユーザが環境変数
>> `QUOTING_STYLE' を設定しているかもしれないから気をつけろ」というのが
>> 無意味な忠告になりますし。
>
> アプリケーションは、ls --dired を呼び出すものはなんでもだと思います。
> シェルスクリプトでもいいでしょうし、アプリケーションの中から system 関数
> などを使ってコマンドを呼び出すようなものもあると思います。
プログラミングをなさる方にとっては、「--dired を使用するアプリケーション
では」でもすんなり理解できるということですね。問題は、わたしのような
プログラミングの経験がない一般ユーザ (というか、初中級者) なんです。
そういう人にとって、アプリケーションと言うと、ワープロや表計算を連想
します。そこで、「--dired を使用するアプリケーション」と言われると、
何のことだかさっぱりわからなくなってしまいます。わたしが「シェルスクリプト
のような」と補充したのは、それが理由です。もっとも、「シェルスクリプトも
アプリケーションだ」というのも、一般ユーザにとっては、かなり違和感が
あるかもしれません。結局、"application" と「アプリケーション」はかなり
意味が違うということで、いや、と言うより、初中級ユーザと上級ユーザで
"application/アプリケーション" の意味にずれがあるということで、
"application" を訳すたびに、いつでも難しいなと思います。何を言っている
のか初中級ユーザにもわかるような、うまい訳し方があるとよいのですが。
もっとも、この部分については、--dired なんて一般ユーザは使わない、
こんな部分は読まない、だから、一般ユーザのことは考えなくてもよい、と
割り切ってしまっても構わないかもしれません。
>> If you use a quoting style that adds quote marks (e.g.,
>> `--quoting-style=c'), then the offsets include the quote marks.
>> So beware that the user may select the quoting style via the
>> environment variable `QUOTING_STYLE'. Hence, applications using
>> `--dired' should either specify an explicit
>> `--quoting-style=literal' option (aka `-N' or `--literal') on the
>> command line, or else be prepared to parse the escaped names.
>>
>> 引用符を付加するクォート方式を使用している場合には (たとえば、
>> `--quoting-style=c')、引用符もオフセットの示す範囲に含まれる。
>> そこで、気をつけるべきことがある。ユーザが環境変数 `QUOTING_STYLE'
>> を設定して、そうしたクォート方式を選択しているかもしれないのだ。
>> 従って、`--dired' を使用するシェルスクリプトのようなアプリケー
>> ションでは、コマンドラインで明示的に `--quoting-style=literal'
>> オプションを指定するか (`-N' や `--literal' でも同じことになる)、
>> エスケープされた名前を解析するようにしておくか、どちらかをする
>> べきだということになる。
>
> したがって、以下ですが、
> --dired を使用するアプリケーションでは、
> コマンドラインで明示的に --quoting-style=literal オプションを指定するか、
> そうでない場合は（オプションを指定しない場合は）、
> エスケープされた名前も解析できるようにしておくべきである。
> ということだと思います。
>
> else をどのように訳すかだと思いますが、お任せいたします。
"be prepared to parse" は「解析するようにしておく」より「解析できる
ようにしておく」の方がよいですね。これはいただきます。"either ...
or else" の訳し方は、どちらでもよさそうな。
>> 10.1.6 タイムスタンプのフォーマット
>>
>> Time stamps are listed according to the time zone rules specified
>> by the `TZ' environment variable, or by the system default rules if
>> `TZ' is not set. *Note Specifying the Time Zone with `TZ': (libc)TZ
>> Variable.
>>
>> タイムスタンプは、環境変数 `TZ' で指定されているタイムゾーンの
>> ルールに従って表示される。`TZ' が設定されていない場合は、システム
>> のデフォルト・ルールに従う。*Note Specifying the Time Zone with `TZ':
>> (libc)TZ Variable.
>>
>> この文章は ls だけでなく、あちこちで出てきますが (pr, stat, who)、
>> "the time zone rules" (タイムゾーンのルール) というのは、どういうこと
>> なんでしょうか。訳文は意味が通じるでしょうか。
>
> 私もソースをみたわけではありませんが、
> TZ 環境変数は JST-9 といった指定以外にサマータイムも含めた指定 (EST9EDT など)
> といった指定も可能です。この解釈ルールに基づいて時間が決まるということでは
> ないでしょうか。
ごめんなさい。まだよくわかりません。
TZ=JST-9 なら UTC より 9 時間進んでいる日本時間を、TZ=EST5EDT なら UTC
より 4 時間遅れているアメリカの東部標準時 (夏時間) を使用するというのが
ルールだ、ということですか。
TZ=EST5 の外に、TZ="America/New_Your" といった指定法もあるでしょう。
こちらを使って date コマンドを実行すると、現在ならニューヨークの時刻が
夏時間で表示されます。冬になってから実行すれば、多分冬時間が表示される
でしょう。わたしとしては、「タイムゾーンのルールにしたがって表示される」
というのは、もしかしたら、それを言っているのではないか、と思いました。
つまり、標準時/夏時間があるところでは、それにしたがって時刻表示がされる
ということでは、と。ただ、やっぱり訳文が (そもそも原文が) 曖昧な気が
しますけれど。
>> 11.1 `cp'
>>
>>
>> `--reflink[=WHEN]'
>> Perform a lightweight, copy-on-write (COW) copy, if supported by
>> the file system. Once it has succeeded, beware that the source
>> and destination files share the same disk data blocks as long as
>> they remain unmodified. Thus, if a disk I/O error affects data
>> blocks of one of the files, the other suffers the same fate.
>>
>> ファイルシステムがサポートしていれば、軽便コピー、すなわち、
>> 書き込み時コピー (copy-on-write (COW) copy) を行う。留意すべきは、
>> これが成功した場合、コピー元とコピー先のファイルは、どちらかに
>> 対して変更が加えられるまで、ディスクの同じデータブロックを共有
>> しているということである。従って、ディスク I/O エラーが起きて、
>> 片方のファイルのデータブロックが損傷を受ければ、もう一方の
>> ファイルも同じ被害に会う。
>>
>> copy-on-write (COW) copy がどんなものかわからないまま訳しています。
>> lightweight は copy にかかるのでしょうか、それとも copy-on-write (COW)
>> copy 全体にかかるのでしょうか。lighweight をどう訳すかも問題です。
>> 「軽便コピー」は「軽便カミソリ」や「軽便鉄道」を連想していますが、
>> ちと古くさい言葉かもしれません。でも、今調べたら、ja.wikipedia.org に
>> 「軽便鉄道」が載っていました。まだ現役の言葉なのかも。 いっそ「ライト
>> ウェイト・コピー」にしてしまいましょうか。
>
> 実際にコピーしないという意味で lightweight といっているのだと思います。
> 「軽量の」「軽い」といったニュアンスが出ていれば十分だと思います。
> カンマをどのように解釈するか悩ましいですが、COW copy にかかるのかなと
> 思います。軽いコピーを行うというよりも、COW copy が軽い処理だという
> ことを言っていると思います。
>
> copy-on-write は、コピーする際には、データのコピーは行わずに、参照元
> だけを増やし、その後書き込みがあり変更が行われた際に、必要な部分だけ
> 書き換えることを指します。
ご説明で copy-on-write がどんなものかわかったような気がします。
COW copy にも重いものと軽いものがあるのですか。もし、一般に軽いものなら、
lightweight の掛かり方が厳密にはどうであれ、lightweight copy と COW copy
を同格のように扱っておけば、よさそうですね。とすると、このままでよさそう。
「軽便」は、古いのはわかっているのですが、lightweit の訳としてピッタリ
と言えばピッタリですし、実は古さをおもしろがっているのです。
>> 11.2 `dd'
>> `sparse'
>> Try to seek rather than write NUL output blocks. On a file
>> system that supports sparse files, this will create sparse
>> output when extending the output file. Be careful when using
>> this option in conjunction with `conv=notrunc' or
>> `oflag=append'. With `conv=notrunc', existing data in the
>> output file corresponding to NUL blocks from the input, will
>> be untouched. With `oflag=append' the seeks performed will
>> be ineffective. Similarly, when the output is a device
>> rather than a file, NUL input blocks are not copied, and
>> therefore this option is most useful with virtual or pre
>> zeroed devices.
>>
>> 出力ブロックが NUL のみからなっているとき、それを書き出さず
>> に、seek を試みる。穴空きファイル (sparse file) をサポート
>> しているシステムでは、この動作は、出力ファイルを書き出して
>> いるときに、穴空きの出力を作成することになる。このオプションを
>> `conv=notrunc' や `oflag=append' と一緒に使う際は、気をつけ
>> なければならない。`conv=notrunc' が付いていると、入力中の NUL
>> ブロックに対応する位置にある、出力ファイル中の存在するデータは、
>> そのまま保持されることになる。`oflag=append' を付けた場合は、
>> seek は行っても効果がない。なお、`conv=sparse' では、出力先が
>> ファイルではなく、デバイスの場合も、入力中の NUL ブロックは
>> やはりコピーされない。そんなわけで、このオプションが最も役に
>> 立つのは、バーチャルデバイスや前もってゼロバイト処理した
>> デバイスに対してである。
>>
>> "Similarly, when the output is a device rather than a file," の
>> Similarly は、何と同様なのでしょうか。一応、「conv=sparse では、
>> 出力先が sparse file をサポートしたファイルシステムのファイルである
>> 場合、出力先は穴空きファイルになる。すなわち、入力中の NUL ブロックは
>> コピーされない。出力先がデバイスの場合も同様に NUL ブロックはコピー
>> されない」と取りました。実際にそういう動作をするのでしょうか。
>
> デバイスの場合でもファイルの場合と同じだと言っているだけだと思います。
> 同様なのは、それ以前の説明全部だと思います。 (Try to seek ... 以降)
> 具体的にいうと、出力ブロックが NUL だけであれば、デバイスへのアクセスを
> 行わずに、オフセットだけを進めるということになります。
>
>> therefore 以下についても、「このオプションは virtual or pre zeroed
>> devices に対して一番役に立つ」というのが何故なのか、わかりません。
>>
>> "pre zeroed devices" とは、どういうことなのでしょう。また、どう訳す
>> のが適切なのでしょうか。
>
> VM などで利用する仮想ディスクなどがよい例です。
> 書き込みがあった際に領域を実際に確保していくタイプの仮想ディスクだと、
> 0 であっても書き込みを行うとファイルサイズが増えてしまいますが、
> 0 の場合に書き込みを行わなければ、ファイルサイズが増えることがありません。
> 結果的に、数GB のファイルコピーを VM 内で行っても、ホスト側で見ると
> ファイルサイズがほとんど増えない場合もあります。すごい効率的ですよね。
そうか。それが「一番役に立つ」ということですか。
> virtual device は「仮想デバイス」の方がしっくり来ます。
> 仮想ディスク、などの表現はよく使うと思います。
> pre zeroed device はしっくり来る訳がなかなかありませんが、
> 「0 で初期化されたデバイス」とか「0 で埋められたデバイス」
> くらいでも十分に思います。
Similarly を表に出しましょうか。こんな具合に。
... なお、以上のことは、出力先がファイルではなく、デバイスの
場合も同じであり、 入力中の NUL ブロックはやはりコピーされない。
そんなわけで、このオプションが最も役に立つのは、仮想デバイスや
前もって 0 で初期化されたデバイスに対してである。
>> dd の iflag と oflag の引数について。
>>
>> `cio'
>> Use concurrent I/O mode for data. This mode performs direct
>> I/O and drops the POSIX requirement to serialize all I/O to
>> the same file. A file cannot be opened in CIO mode and with
>> a standard open at the same time.
>>
>> データに対してコンカレント I/O (CIO) モードを使用する。この
>> モードはダイレクト I/O を行い、さらに、同じファイルに対する
>> すべての I/O は直列的に行うべしという、POSIX の要求を緩和
>> する。一つのファイルを CIO モードと標準的な方法の、両方で
>> 同時にオープンすることはできない。
>>
>> まったく理解しないで訳しています。内容的に大丈夫でしょうか。
>
> ダイレクト I/O を行うと、ファイルの I/O は順番に行われるわけではないので、
> POSIX の要件に違反することになります。
>
> ダイレクト I/O を行い、〜という POSIX の要件は無視される
>
> くらいでしょうか。
>
> 最後の文は、「両方の」の直前の読点に違和感があります。
>
> CIO モードと標準的な方法の両方で、
> 一つのファイルを同時にオープンすることはできない。
そうですね。なんで「両方の、」と点を付けたんでしょう。全文を書き直すと、
データに対してコンカレント I/O (CIO) モードを使用する。この
モードでは、ダイレクト I/O を行いつつ、同じファイルに対するすべての
I/O は直列的に行わなければならないという POSIX の要件の方は無視する。
一つのファイルを CIO モードと標準的な方法の両方で同時にオープンする
ことはできない。
>> `dsync'
>> Use synchronized I/O for data. ...
>>
>> データに対して同期された I/O を使用する。
>
> いい訳がないのですが、通常 synced IO というと
> ディスクまでの書き込みを保証する意味になります。
> 「同期 I/O」くらいかなぁ？
>
> ファイルキャッシュに書き込んで終わりというコピーモードもありますので。
>
> write back と write through の違いとだいたい同じだと思います。
「データに対して同期 I/O を使用する」で充分ですか。
>> `fullblock'
>> Accumulate full blocks from input. The `read' system call
>> may return early if a full block is not available. When that
>> happens, continue calling `read' to fill the remainder of the
>> block. This flag can be used only with `iflag'.
>>
>> 各ブロックが一杯になるまで入力から読み込む。`read' システム
>> コールは、入力がブロックの分量に足らない場合、早めに戻って
>> くるかもしれない。そうした場合には、`read' の呼び出しを繰り
>> 返して、ブロックの残りを埋めようとする。このフラグは、`iflag'
>> でのみ使える。
>>
>> "Accumulate full blocks" と block が複数ですから、素直に読むと、
>> 「入力からブロックサイズ一杯のデータを次々に読み込んで、蓄積する」と
>> なりそうですが、dd というのは、基本的にブロックサイズ分データを読み
>> 込んだら、すぐに書き出すものなんでしょう。それに、以下の文を読むと、
>> accumulate と言っても、複数のブロックを溜め込むのではなく、各ブロックが
>> 一杯になるまでデータを溜め込むということのようです。そこで、上のような
>> 訳にしましたが、無理な解釈かもしれません。
>
> 入力でブロック全体のデータが揃うまで待つ、という意味だと思います。
> 通常は、ブロック全体のデータが揃っていなくても read が変えることがあり、
> 後続の read で残りのデータを読み出すことになるが、
> このオプションを使うと read を何度も行う必要がなくなるということだと
> 読み取りました。
このフラグを使うと、入力データがブロックサイズに足りない場合、その
ブロックが一杯になるまで自動的に read するようになるから、意識的に read
する必要がなくなるということですか。だとしたら、わたしの解釈と大体同じ
ですね。パイプから読み込んでいるときのことなんかでしょうか。
>> 11.6 `shred'
>>
>> 「shred はバッドセクターにあるデータを破壊できない」と述べた後で、
>>
>> `shred' makes no attempt to detect or report this problem, just as
>> it makes no attempt to do anything about backups. However, since it
>> is more reliable to shred devices than files, `shred' by default does
>> not truncate or remove the output file. This default is more
>> suitable for devices, which typically cannot be truncated and
>> should not beremoved.
>>
>> `shred' は、バックアップに対して何の対処も行おうとしないのと全く同様
>> に、上記の問題についても検知しようともしないし、通知しようともしない。
>> それでも、ファイルを shred するより、デバイスを shred する方が信頼
>> できる。そこで、`shred' はデフォルトでは、出力ファイルをサイズ 0 に
>> 短縮したり、削除したりしない。デバイスは一般に短縮できないし、削除する
>> べきでもないので、このデフォルトは、デバイスにとってよりふさわしい
>> 動作である。
>>
>> "However, since" 以下の論理がよくわかりません。「ファイルを shred する
>> より、デバイスを shred する方が信頼できる。だから、shred のデフォルトは、
>> デバイス向けの設定になっている」と、一応解釈しました。
>
> about backups の、バックアップ、が何かはよくわかりませんが、
> ファイルのバックアップがあるようなファイルシステムの場合に、
> バックアップを削除するようなことはしないという、というのが最初の文だと
> 思います。
文脈がないとわかりにくいですね。と言うよりも、ここで原文がバックアップに
触れていることには、ちょっと無理があります。実はバックアップやミラーに
ついては、次のパラグラフに書いてあるのです。「最後になったが、バック
アップやミラーの持つリスクも考慮した方がよい ...」という具合に。おそらく、
この部分を新しく追加したときに、文脈が乱れたのだろうと思います。
文脈について言うと、「ファイルシステムによっては、shred は効果がない」
と書かれ、そうしたファイルシステムとして、ログ構造化ファイルシステム、
ジャーナル化ファイルシステム、Raid ベースのファイルシステムなどが
挙げられています。そして、次のパラグラフが来ます。
一般的に言って、`shred' は、ファイルよりデバイスに対して使った方が
信頼できる。そうすれば、上に述べたファイルシステムの設計の問題を回避
できるからだ。しかしながら、`shred' のデバイスに対する使用も、必ずしも
全面的に信頼できるというわけではない。たとえば、ほとんどのディスクが
バッドセクターを、使用に割り当てる領域から外し、アプリケーションから
見えないようにしている。そこで、バッドセクターに他人に見られたくない
データがある場合、`shred' はそれを破壊できないことになる。
問題のパラグラフはこの後にあるのです。もっとも、ジャーナル化ファイル
システムや Raid もバックアップと言えるかもしれませんけれど。
> これを踏まえると、ファイル単体に対して shred を行うよりも、
> ファイルシステムが入っているデバイスに対して shred を実行する方が
> 確実にデータを消すことができるということだと思います。
> more reliable となっているのは、badblock の面倒は見ず、すっ飛ばすので、
> 必ず reliable かというとそうではないからだと推測します。
というわけで、ご推察のとおりです。
> こうした背景を踏まえて however 以降につながっていると思います。
> 適当に括弧内に行間をおぎなってみます。
>
> ファイルに対して行うよりもデバイスに対して行う方がより確実なので、
> デフォルトでは（デバイスに対して実行するのに適したモードになっていて）
> shred は出力ファイルの切り詰めも削除も行わないようになっている。
> これはデバイスに対して shred を行う場合に適したオプションである。
> 通常、デバイスではファイルの切り詰めを行うことはできないし、
> デバイスの削除も行うべきではないからである。
>
> といった感じでしょうか。
ええ、これもそのとおりだと思います。わたしが困っているのは、"since it is
more reliable to shred devices than files" と "`shred' by default does
not truncate or remove the output file." の間に論理的な飛躍があること
なんです (元木さんもカッコで補っていらっしゃるように)。それで苦労して
いるわけです。
>> 以下は、shred の用例の一つです。
>>
>> A FILE of `-' denotes standard output. The intended use of
>> this is to shred a removed temporary file. For example:
>>
>> `-' という FILE は、標準出力を表している。これの使い道は、削除した
>> テンポラリ・ファイルを shred することである。たとえば、次のようにだ。
>>
>> i=$(mktemp)
>> exec 3<>"$i"
>> rm -- "$i"
>> echo "Hello, world" >&3
>> shred - >&3
>> exec 3>-
>>
>> 何をやっているのか、よくわかりません。要するに、rm で消したファイルの
>> ディスク上に残っているデータの上書きをするということですか。
>> なお、"exec 3>-" は、fd 3 を閉じるということなら、"exec 3>&-" では
>> ないでしょうか。"exec 3>-" だと、カレントディレクトリに "-" という
>> ファイルができてしまうようです。
>
> ファイルの削除はファイルシステム上での参照を削除するだけで、
> すでにオープンされているファイルはそのまま利用できます。
> そのファイルがクローズされるまではデータはディスク上には書き込まれます。
>
> ここでは exec 3<>"$i" で mktemp で作成したファイルを読み書きモードで
> オープンして、ファイルを消して、そのファイルの領域に書き込みを行っています。
> その後で shred を標準出力に対して行うと、標準出力が fd 3 にリダイレクト
> されて、fd 3 は tempfile に対応している（exec 3<>"$i"）ので、結果的に
> tempfile に対して shred がおこなわれます。
>
> fd 3 をクローズする意味なので、最後は 3>&- が正しいはずです。
よくわかりました。最後のところは "exec 3>&-" に直しておきます。
--
長南洋一