cat x >> xがループするのはなぜですか？

次のbashコマンドは無限ループに入ります。

$ echo hi > x
$ cat x >> x

stdoutへの書き込みを開始catしたx後から読み続けていると推測できます。ただし、混乱を招くのは、私自身のcatのテスト実装が異なる動作を示すことです。

// mycat.c
#include <stdio.h>

int main(int argc, char **argv) {
  FILE *f = fopen(argv[1], "rb");
  char buf[4096];
  int num_read;
  while ((num_read = fread(buf, 1, 4096, f))) {
    fwrite(buf, 1, num_read, stdout);
    fflush(stdout);
  }

  return 0;
}

私が実行した場合：

$ make mycat
$ echo hi > x
$ ./mycat x >> x

ループしません。の動作catと、stdout以前にフラッシュしているという事実がfread再び呼び出されることを考えると、このCコードはサイクルで読み取りと書き込みを続けると予想されます。

これら2つの動作はどのように一貫していますか？cat上記のコードがループしないのにループする理由を説明するメカニズムは何ですか？

私が持っている古いRHELシステムで/bin/catは、ループしませんcat x >> x。cat「cat：x：入力ファイルは出力ファイルです」というエラーメッセージが表示されます。これを行うことで私はだますことができ/bin/catますcat < x >> x。上記のコードを試すと、説明した「ループ」が発生します。システムコールベースの「猫」も作成しました。

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int
main(int ac, char **av)
{
        char buf[4906];
        int fd, cc;
        fd = open(av[1], O_RDONLY);
        while ((cc = read(fd, buf, sizeof(buf))) > 0)
                if (cc > 0) write(1, buf, cc);
        close(fd);
        return 0;
}

これもループします。ここでのバッファリングは（stdioベースの「mycat」とは異なり）カーネルで行われることだけです。

私は何が起こっていることは、そのファイルディスクリプタ3（の結果だと思うopen(av[1])0に提出記述子1（標準出力）のファイルにオフセットしている）、「>>」を行うために起動したシェルが発生するため、3のオフセットたlseek()上でcat子プロセスに渡す前にファイル記述子。

read()stdioバッファーまたはプレーンへの任意の種類のa を行うと、char buf[]ファイル記述子3 write()の位置が進みます。aを行うと、ファイル記述子1の位置が進みます。これら2つのオフセットは異なる数値です。「>>」のため、ファイル記述子1には常にファイル記述子3のオフセット以上のオフセットがあります。したがって、何らかの内部バッファリングを行わない限り、「猫のような」プログラムはループします。それは、多分、おそらく可能だというのstdioの実装FILE *（シンボルのタイプであるstdoutとf独自のバッファが含まれるコード内で）。fread()実際にシステムコールread()を行って、内部バッファfoを埋めfます。これにより、の内部の何も変更されない場合がありstdoutます。呼び出しfwrite()にstdout内の何も変更しない場合がありfます。そのため、stdioベースの「猫」はループしない可能性があります。またはそれかもしれません。多くの見苦しい、見苦しいlibcコードを読まずに言うのは難しい。

私はstraceRHELでやったcat-それは単にシステムコールの連続をread()行いwrite()ます。しかし、a catはこのように動作する必要はありません。mmap()入力ファイルが可能になりますwrite(1, mapped_address, input_file_size)。カーネルがすべての作業を行います。またはsendfile()、Linuxシステムで入力ファイル記述子と出力ファイル記述子の間でシステムコールを実行できます。古いSunOS 4.xシステムはメモリマッピングのトリックを行うと噂されていましたが、sendfileベースのcatを実行したことがあるかどうかはわかりません。いずれの場合においても、「ループ」の両方として、起こらないであろうwrite()とsendfile()長さと転送パラメータを必要とします。

最新のcat実装（sunos-4.0 1988）は、mmap（）を使用してファイル全体をマップし、このスペースに対して1x write（）を呼び出します。このような実装は、仮想メモリがファイル全体をマップできる限りループしません。

他の実装では、ファイルがI / Oバッファより大きいかどうかによって異なります。

Bash pitfallsに書かれているように、同じパイプラインでファイルから読み取り、書き込むことはできません。

パイプラインの動作に応じて、ファイルは上書きされる場合があります（0バイト、またはオペレーティングシステムのパイプラインバッファーのサイズに等しいバイト数まで）、または利用可能なディスク領域がいっぱいになるか、または到達するまで大きくなる場合がありますオペレーティングシステムのファイルサイズの制限、またはクォータなど。

解決策は、テキストエディターまたは一時変数を使用することです。

両方の間に何らかの競合状態がある xます。cat（たとえばcoreutils 8.23）の一部の実装では、次のことが禁止されています。

$ cat x >> x
cat: x: input file is output file

これが検出されない場合、動作は明らかに実装（バッファサイズなど）に依存します。

コード内で、ファイルの終わりインジケータが設定されている場合に次がエラーを返す場合に備えて、のclearerr(f);後にを追加することができます。fflushfread