Чи безпечно перенаправляти stdout та stderr до одного файлу без копій дескриптора файлу?

Я починаю з порожнього каталогу.

$ touch aFile
$ ls
aFile

Тоді я lsдва аргументи, жодного з яких немає в цьому каталозі. Я перенаправляю обидва вихідні потоки у файл з назвою output. Я використовую >>, щоб не писати одночасно.

$ ls aFile not_exist >>output 2>>output
$ cat output
ls: cannot access 'not_exist': No such file or directory
aFile

Який, здається, працює. Чи є небезпека такого підходу?

Ні, це не так безпечно, як стандарт >>bar 2>&1.

Коли ти пишеш

foo >>bar 2>>bar

Ви відкриваєте barфайл двічі O_APPEND, створюючи два абсолютно незалежних файлових об'єкта [1], кожен з яких має свій стан (вказівник, відкриті режими тощо).

Це дуже не на відміну від того, 2>&1що просто викликає dup(2)системний виклик, і робить stderr і stdout псевдонімами, що змінюються, для одного і того ж файлового об’єкта.

Тепер у цьому є проблема:

O_APPENDможе призвести до пошкодження файлів у файлових системах NFS, якщо більше одного процесу додає дані до файлу одночасно. Це тому, що NFS не підтримує додавання до файлу, тому ядро ​​клієнта має імітувати його, що неможливо зробити без умови перегону.

Зазвичай ви можете розраховувати на ймовірності файлу , як barв foo >>bar 2>&1записуються одночасно з двох різних місць , які є досить низькими. Але своїм >>bar 2>>barви просто збільшили його на десяток порядків, без будь-яких причин.

[1] "Відкрити описи файлів" в мові POSIX.

Що відбувається, коли ти робиш

some_command >>file 2>>file

є те, що fileбуде відкрито для додавання двічі. Це безпечно робити у файловій системі POSIX. Будь-яке записування, яке трапляється у файл під час відкриття для додавання, відбуватиметься в кінці файлу, незалежно від того, надходять дані над стандартним вихідним потоком або стандартним потоком помилок.

Це спирається на підтримку операцій запису атомного додавання в базовій файловій системі. Деякі файлові системи, такі як NFS, не підтримують атомне додавання. Дивіться, наприклад, питання "Чи додається файл атомним в UNIX?" На StackOverflow.

Використання

some_command >>file 2>&1

хоч би працював навіть на NFS.

Однак, використовуючи

some_command >file 2>file

не є безпечним, оскільки оболонка урізає вихідний файл (двічі), і будь-яка запис, що відбувається в будь-якому потоці, замінить дані, вже написані іншим потоком.

Приклад:

$ { echo hello; echo abc >&2; } >file 2>file
$ cat file
abc
o

helloРядок записується першим (з кінцевим нового рядка), а потім рядок з abcподальшим переведенням рядка записується зі стандартної помилки, перезапису hell. В результаті виходить рядок abcз новим рядком, після чого слід залишити перший echoвихід, а oта новий рядок.

Заміни двох echoнавколо рани виробляються лише helloу вихідному файлі, оскільки ця рядок пишеться останньою та довшою за abcрядок. Порядок, в якому відбуваються переадресації, значення не має.

Краще і безпечніше було б використовувати більш ідіоматичне

some_command >file 2>&1

Це залежить того, чого ви хочете досягти. Ви вирішуєте, чи гаразд помилки у тому ж файлі, що і у вихідному. Це просто збереження тексту у файлі з функціональністю оболонки, яка дозволяє перенаправляти за бажанням. Не існує абсолютного «так» або «ні». Оскільки у Linux це можна зробити декількома способами, це мій спосіб ls notExistingFile existingFile >> output 2>&1 відповісти на питання: З точки зору самого перенаправлення, так, це абсолютно безпечно.