シェルスクリプトでどのように簡単にできますか?非侵襲的実際にファイルを変更しようとせずにファイルへの書き込みアクセスをテストしますか?
出力を解析できますが、stat
統計出力が実装とタイミングにどのように大きな違いをもたらすかはわかりませんが、これは非常に複雑で不安定になる可能性があります。
ファイルの末尾に追加して成功することを確認できますが、これは2つの理由で危険です。
- これで追加のエントリを削除する必要があります。これは私の行がもはや最後の行ではないので、他のプロセスがファイルに書き込む場合、すぐに非常に重要になります。
- ファイルを読み取るすべてのプロセスには、ファイルの内容に関する任意の要件がある可能性があり、アプリケーションが中断される可能性があります。
答え1
ちょうど使用 -w
フラグtest
公益事業:
[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"
後でファイルに書き込もうとすると、まだファイルに書き込めない可能性があります。ファイルが移動されたか、権限が変更された可能性があります。次のような状況も発生する可能性があります。-w
書き込み権限が検出されましたが、ファイルを書き込めないようにするために他の要因が介入しました。。
答え2
別の方法:
if >> /path/to/file
then
echo "writeable"
else
echo "write permission denied"
fi
その後、追加するファイルを開こうとし、成功した場合 走る注文不可(つまり、空のコマンドの実行) ファイルに出力します。
ファイルが存在しない場合は、空のファイルが生成されます。
-w
コマンド・オペレーターはtest
単に a を実行し、stat
ユーザーにアクセス権が必要かどうかを判断しようとすることができます。いくつかの特別なケースでは、上記の選択肢がtest
シェルではなくカーネルによってアクセスチェックを強制するため、この方法よりも信頼性が高くなります。例えば、
- ファイルがUnix以外のファイルシステムにある場合(特にUnix以外のファイルサーバーからリモートでマウントしている場合)、
stat
無効なモード値が返される可能性があります。 - ファイルが読み取り専用でマウントされたファイルシステムにある場合。
- ファイルにACLがあり、パターンはアクセス権を持っている必要があるように見えますが、ACLがそれを拒否するか、その逆です。
- 一部のセキュリティフレームワーク(AppArmor、SELinuxなど)がファイルへのアクセスを拒否する場合。
答え3
G-manは正しいです:[ -w ]
いいえ。いつも正直に言うと。存在しないファイルを処理し、許可が拒否されましたシェルから送信されたメッセージ:
( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null &&
echo writable ||
echo not writable
修正する:ちょっと怖いと思いませんか?まあ。まあ…どのように表現しますか…期待どおりに動作しなければならない状況にあることを完全に知らない限り、これを使用しないでください。 Stephenのコメントを参照してください。
それでは、どのような結論が下されますか?事実を言わなくても[ -w ]
命令はこれだけだ故意にタスクを実行します。そうでなければ、私たちはそれを非難し、バグレポートを作成します。その後、今後は機能します。それが機能し、使用されている条件をよりよく確認してください[ -w ]
。特別なケースのための特別なコードを書いてください。ソリューションには独自の条件があります。
[ -w /path/to/file ]
それが一番です。先験的に。