私がするなら：
at -f <(echo "rm $file") now + 2 hours
良い結果
しかし、これを行うと：
sudo at -f <(echo "rm $file") now + 2 hours
私は得る:
at: /dev/fd/63: No such file or directory
私はこれがコマンドが処理される順序のためだと思います。 sudoコマンドを使用してこの問題を解決する方法はありますか？私が考えることができる唯一の方法は、コマンドをスクリプトに入れてスクリプトをsudoすることです（それはオプションです）。ところで、なぜこれが起こるのか疑問に思います。
この質問に対する答えがすでにどこかにあった場合は申し訳ありません。何を探すべきか分からないので見つかりません。
ベストアンサー1
シェルはコマンドのパイプを開き、<(...)実行される子プロセスにファイルハンドルを渡すためです（sudoこの場合）。 Path/dev/fd/63は、通常のパス名ですでに開いているファイルハンドルへのアクセスを許可するカーネルによって提供される方法です。
ただし、sudoハンドルはセキュリティ上の理由で実行されるプロセスには渡されません。デフォルトでは、stdin、stdout、stderrを除くすべてのファイルハンドルを閉じるので、最終的に実行するプログラムにはそのファイルがなく、/dev/fd/63ハンドルが正しくありません。
sudo内のシェルを交換することでこの問題を解決できます。
sudo bash -c 'cat <(echo something)'
もちろん、これは内部交換も高い権限で実行されることを意味します。
$ sudo bash -c 'cat <(id)'
uid=0(root) gid=0(root) groups=0(root)
フラグは他の方法を-C提供しますsudoが、追加の設定を許可する必要があるかもしれません。
-C 番号、 --close-from=番号
コマンドを実行する前に、num以上のすべてのファイル記述子を閉じます。 3未満の値は許可されません。デフォルトでは、sudoはコマンドを実行すると、標準入力、標準出力、および標準エラーを除くすべての開いているファイル記述子を閉じます。セキュリティポリシーによっては、ユーザーがこのオプションを使用する機能が制限されることがあります。 sudoersポリシーは、管理者がclosefrom_overrideオプションを有効にした場合に-Cオプションのみを許可します。