Linuxで「>>」を使用すると、bashはO_APPENDでファイルを開きますか？

使用するとecho 1234 >> some-file、ドキュメントに出力が追加されると記載されています。

私の推測では、いくつかのファイルが存在しない場合、O_CREATは新しいファイルを作成します。もしを>使用し、その後、O_TRUNCは、既存のファイルが切り捨てられます。

次の場合>>：ファイルはO_WRONLY（またはO_RDWR）として開かれ、終了を求めてO_APPENDをシミュレートして書き込み操作が行われますか？または、ファイルがO_APPENDとして開かれ、追加を確実に行うためにカーネルに残されますか？

出力ファイルがNFSマウントポイントからのものである場合、コンサーバープロセスがエコーによって挿入されたいくつかのマーカーを上書きしているため、私はこれを求めています＆NFSドキュメンテーションはO_APPENDがサーバーでサポートされていないため、クライアントカーネルがそれを処理する必要があると述べています。私はconserverプロセスがO_APPENDを使用していると思いますが>>、Linux でbashが確実でないため、ここで質問します。

私はこれを実行しました：strace -o spork.out bash -c "echo 1234 >> some-file"あなたの質問を理解するため。これは私が見つけたものです：

open("some-file", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3

echoコマンドを実行したディレクトリに「some-file」という名前のファイルが存在しませんでした。

これはBashで行われるだけでなく、標準で要求されています。

Single Unix Specificationから：

付加された出力リダイレクトにより、指定されたファイル記述子での出力のために、wordの展開から名前が得られたファイルが開かれます。ファイルは、POSIX.1-2008のSystem Interfacesボリュームで定義されているopen（）関数がO_APPENDフラグで呼び出されたかのように開かれます。ファイルが存在しない場合は作成されます。

したがって、POSIX準拠のシェルはそれを行う必要があります。一部のUNIXシステムでは、/bin/sh非POSIX Bourneシェルであってもよい（Bourneシェルは、もともと前に書かれたO_APPEND発明された）、そして利用可能なPOSIXシェルは、典型的にはkshとして利用できるようになる、shそのようなSolarisののような異なる経路の場所に/usr/xpg4/bin。

ソースを見ると、O_APPENDが使用されています。make_cmd.c710-713行のbash 4.3.30の場合：

case r_appending_to:                /* >>foo */
case r_append_err_and_out:          /* &>> filename */
  temp->flags = O_APPEND | O_WRONLY | O_CREAT;
  break;

straceローカル（NFS以外）ファイルシステムで使用することを調査してみましょう。

$ strace -eopen -- bash -c "echo foo >> /tmp/testfile000" 2>&1 | grep /tmp/testfile000
open("/tmp/testfile000", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3

$ strace -eopen -- bash -c "echo foo > /tmp/testfile000" 2>&1 | grep /tmp/testfile000
open("/tmp/testfile000", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3

つまり他のシェル、dash、dash、shbusyboxのの」とmksh同じように振る舞います。

このオプション-e openは-e trace=open、open()システムコールのみをトレースすることを意味します。