
スクリプト/ファイルの終わりをどのように判断したのでしょうか? 私は特に古い Unix バージョン (V6 など) に興味があります。
最後に書き込んだ文字の後に「\0」がありますか?
答え1
さらに古い Unix のユーザーランド プログラムでは、ファイルの末尾の「パディング」バイトは認識されませんでした。MS-DOS または CP/M ではディスク ブロックが Ctrl-Z 文字で埋められるため、ファイル読み取りアルゴリズムではディスク ブロックの末尾をチェックするだけでなく、パディング バイトもチェックする必要がありました。
Unix ではそのようなことは決して行われませんでした。プログラムは、ファイル終了条件が発生するまでバイトを読み取ります。これは、read(2)
システム コールの場合、0 を返すことを意味します。残念ながら、長時間実行されるシステム コールは中断される可能性があり、その場合、read()
エラー コード (-1) が返され、グローバル シンボルはerrno
EINTR と評価されます。そのため、Unix では、特定のデバイスの読み取りに、伝統的にいくつかのおかしな点が導入されています。
これにはファイル システムの側面もあります。Unix ファイル システムはデータをディスク ブロックに格納し、ファイル サイズのバイト値を inode に保持します。他の OS の中には、ファイル サイズをブロック単位でのみ保持するものもあります。データがブロックより小さい場合、問題は pad bytes などの意味のない方法でユーザー ランドにまで広がります。
答え2
必ずしもそうではありません。シェル インタープリタは、何らかの (多かれ少なかれ複雑な) システムコール ラッパー (例: read()
)を使用してスクリプトでファイルを読み取りfread()
、ファイルの最後のバイト (ゼロである必要はありません) に達するとファイル終了状態を通知します。