Чи належать звіти про хід роботи / реєстрація інформації про stderr чи stdout?

Чи є офіційні POSIX, GNU чи інші вказівки щодо того, де слід надрукувати звіти про хід роботи та реєстрацію інформації (такі як "Doing foo; foo done")? Особисто я схильний писати їх до stderr, щоб я міг перенаправляти stdout і отримувати лише фактичний вихід програми. Нещодавно мені сказали, що це не є хорошою практикою, оскільки звіти про прогрес насправді не є помилками, а на stderr слід надрукувати лише повідомлення про помилки.

Обидві позиції мають сенс, і, звичайно, ви можете вибрати ту чи іншу залежно від деталей того, що ви робите, але я хотів би знати, чи є для цього загальноприйнятий стандарт. Мені не вдалося знайти жодних конкретних правил у POSIX, стандартах кодування GNU чи будь-яких інших таких загальновизнаних списках найкращих практик.

У нас є кілька подібних запитань, але вони не вирішують цю точну проблему:

• Коли використовувати перенаправлення на stderr у скриптах оболонки : Прийнята відповідь підказує, що я прагну робити, тримати остаточний вихід програми на stdout і все інше на stderr. Однак це просто представлено як думка користувача, хоча і підтримується аргументами.

• Чи повинно повідомлення про використання переходити до stderr або stdout? : Це специфічно для довідок, але цитує стандарт кодування GNU. Це те, що я шукаю, не обмежуючись лише довідками.

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

Posix визначає стандартні потоки таким чином :

При запуску програми три потоки мають бути заздалегідь визначені і не повинні відкриватися явно: стандартний вхід (для читання звичайного вводу), стандартний вихід (для запису звичайного виводу) та стандартна помилка (для запису діагностичного виводу). При відкритті стандартний потік помилок не буферизований повністю; стандартні вхідні та стандартні вихідні потоки повністю буферизовані лише тоді, якщо потік можна визначити не відноситься до інтерактивного пристрою.

Бібліотека GNU C описує аналогічні стандартні потоки:

Змінна: FILE * stdout
Стандартний вихідний потік, який використовується для нормального виводу з програми.

Змінна: FILE * stderr
Стандартний потік помилок, який використовується для повідомлень про помилки та діагностики, виданих програмою.

Таким чином, стандартні визначення мають невеликі вказівки щодо використання потоку за межами «звичайного / нормального виходу» та «діагностичного / помилкового виведення». На практиці прийнято перенаправляти один або обидва ці потоки на файли та трубопроводи, де індикатори прогресу будуть проблемою. . Деякі системи навіть контролюють stderr вихід і вважають це ознакою проблем. Таким чином, інформація про допоміжний прогрес є проблематичною для будь-якого потоку.

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

Для деяких дуже простих повідомлень про прогрес ("Починаючи з X" ... "Зроблено з X") розумніше включати вихід навіть для неінтерактивних потоків. У такому випадку подумайте, як користувачі можуть взаємодіяти з потоками, як-от пошук grepабо перехід на сторінку lessабо моніторинг із ними tail -f. Якщо є сенс бачити повідомлення про прогрес у цих контекстах, їх буде набагато простіше споживати stdout.

POSIX визначає стандартну помилку як

для написання діагностичного виводу

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

POSIX трохи конкретніше щодо "діагностичної інформації" у програмі Shell and Utilities , 1.4: Опис утиліти за замовчуванням (наголос моє):

STDERR

Розділ STDERR описує стандартний вихід помилки утиліти. Описані лише ті повідомлення, які спеціально надсилаються утилітою. Використання терміналу для стандартної помилки може зупинити будь-яку зі стандартних утиліт, які записують стандартний вихід помилки, коли використовується у фоновому режимі. З цієї причини програми не повинні використовувати інтерактивні функції у сценаріях, розміщених у фоновому режимі.

Формат діагностичних повідомлень для більшості утиліт не визначений, але на мову та культурні конвенції діагностичних та інформаційних повідомлень, формат яких не визначений цим обсягом POSIX.1-2008, має впливати налаштування LC_MESSAGES та [XSI] [Опція Старт ] НЛСПАТ. [Варіант Кінець]

Зазначений вихід стандартної помилки стандартних утиліт не повинен залежати від існування або значення змінних середовища, визначених у цьому обсязі POSIX.1-2008, за винятком випадків, передбачених цим обсягом POSIX.1-2008.

Поведінка за замовчуванням : Коли цей розділ вказаний як "Стандартна помилка повинна використовуватися лише для діагностичних повідомлень". Це означає, що, якщо не вказано інше, діагностичні повідомлення надсилаються до стандартної помилки лише тоді, коли стан виходу вказує, що помилка сталося, і утиліта використовується як описано в цьому томі POSIX.1-2008.

Якщо цей розділ вказаний як "Не використовується", це означає, що стандартна помилка не повинна використовуватися, коли утиліта використовується, як описано в цьому томі POSIX.1-2008.

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

За принципом виключення воно може перейти лише до більш жорсткого. Так, я знаю, що ви запитали про офіційну специфікацію, яку я не можу представити за межами посилання на специфікацію POSIX, наданої Стівеном Кіттом, в якому зазначено, що stderr призначений для діагностичних цілей.

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

Тому. Ніщо, крім реального «корисного навантаження» вашої програми, не належить до stdout. Якщо у вашої програми немає результатів, то нічого не повинно йти на stdout. Це залишає складніше для всього іншого , включаючи звіти про хід діяльності.

Зрозуміло, це залишає дірку - можливо, було б добре мати "stdfluff" або щось подібне, яке не має жодних результатів, ані помилок, але звітів про прогрес, налагодження та щось подібне. Насправді, ніщо не заважає вам цього робити, тобто ви можете надрукувати свій прогрес у дескрипторі файлів 3. Приклад:

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'

Це не дає результату. (*)

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'  3>&1
hello

Це друкує на fd-3, який перенаправляється на stdout.

(*) Перший приклад не дає результатів, але все ще трохи надуманий; openзазнає невдачі і $!буде містити no such file or directory; просто візьміть це як приклад, це, звичайно, не настільки, щоб серйозно використовувати це. У дійсній програмі, якщо ви хочете пройти цей маршрут, ви можете перевірити, чи /dev/fd/3є він придатним для використання, і сприйняти це як підказку щодо активації ваших звітів про хід; вам доведеться це зробити досить рано, щоб ви не заплуталися у власних opensх для реальних файлів і подібних ...

Повідомлення про використання повинно переходити до stdout, якщо користувач викликав його, --helpі stderr, якщо він допустив помилку. Роздрукувати його на stderr беззастережно - це неприємно, оскільки це ускладнює перегляд його за допомогою пейджера / grep / тощо.

Також, я можу запропонувати третій спосіб: відкрити / dev / tty для звітів про хід / спінери / тощо.