Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему изрядная часть unix-like утилит выводит справку в stderr? ЕМ>На это есть какие-то разумные соглашения, или просто мода такая тупая?
эта изрядная часть, поди, на любые ошибки в командной строке выдаёт справку (а не по -h/--help), тогда ей в stderr самое место.
Здравствуйте, Pzz, Вы писали:
Pzz>Мне кажется, они просто предусмотрели один "аварийный" вывод, и выводят туда и справку и сообщения об ошибках.
Смотрел несколько исходников — там используется и printf, и fprintf с stdout/stderr. В stdout выводят листинги и прочее. Но справку — почему-то явно в stderr.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему изрядная часть unix-like утилит выводит справку в stderr?
ЕМ>На это есть какие-то разумные соглашения, или просто мода такая тупая?
Почему тупая? По мне так — вполне логично. В stdout выдаются результаты работы программы, а всякие служебные сообщения, об ошибках там, или та же справка — в stderr
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>Мне кажется, они просто предусмотрели один "аварийный" вывод, и выводят туда и справку и сообщения об ошибках.
ЕМ>Смотрел несколько исходников — там используется и printf, и fprintf с stdout/stderr. В stdout выводят листинги и прочее. Но справку — почему-то явно в stderr.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему изрядная часть unix-like утилит выводит справку в stderr? ЕМ>На это есть какие-то разумные соглашения, или просто мода такая тупая?
Разве это кому-то мешает? Всегда можно перенаправить вывод "&2>1" если надо.
Здравствуйте, Marty, Вы писали:
M>В stdout выдаются результаты работы программы, а всякие служебные сообщения, об ошибках там, или та же справка — в stderr
И почему же справка, по-Вашему, ближе к "ошибкам", чем к "результатам работы"?
Здравствуйте, Евгений Музыченко, Вы писали:
M>>В stdout выдаются результаты работы программы, а всякие служебные сообщения, об ошибках там, или та же справка — в stderr
ЕМ>И почему же справка, по-Вашему, ближе к "ошибкам", чем к "результатам работы"?
Здравствуйте, Pzz, Вы писали:
Pzz>А кто, например, из более-менее не-экзотических?
Я все уже не вспомню. Сегодня вот попалась ftdiflash (чтение/запись EEPROM через FTDI), неделю назад — reveng (подбор алгоритмов/полиномов CRC). avrdude (программатор MCU AVR) тоже так делает.
А вообще попадалось немало — иногда в поисках нужной утилиты приходится и десяток в день тестировать.
Здравствуйте, kov_serg, Вы писали:
_>Разве это кому-то мешает?
Тем, кто хочет просто пролистать справку, а не заморачиваться с перенаправлением?
_>Всегда можно перенаправить вывод "&2>1" если надо.
А еще можно не выводить справку в stderr, если не надо.
Вопрос же не в том, можно ли с этим бороться, а в том, какая логика лежит в основе такого подхода. Я бегло погуглил, но внятных доводов "за" не нашел, а вот брани разной степени жесткости нашел изрядно.
Здравствуйте, Marty, Вы писали:
ЕМ>>И почему же справка, по-Вашему, ближе к "ошибкам", чем к "результатам работы"?
M>Такая же технологическая информация
Такая же, как что? Что Вы называете "технологической информацией"?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вопрос же не в том, можно ли с этим бороться, а в том, какая логика лежит в основе такого подхода. Я бегло погуглил, но внятных доводов "за" не нашел, а вот брани разной степени жесткости нашел изрядно.
Логика очень простая. В stderr предназначен для вывода диагностических и отладочных сообщений. Вот когда указываете неверный ключ вам вываливают сообщение об ошибке и за одно справку.
А stdout для вывода данных. Поэтому такое поведение вполне логично. Хотя жестких стандартов нет. Все лепят в зависимости от того куда тюбитейка ляжет.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>И почему же справка, по-Вашему, ближе к "ошибкам", чем к "результатам работы"?
M>>Такая же технологическая информация
ЕМ>Такая же, как что? Что Вы называете "технологической информацией"?
Такая же технологическая информация, как и сообщения об ошибках. В отличие от нормального вывода результатов работы программы
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я все уже не вспомню. Сегодня вот попалась ftdiflash (чтение/запись EEPROM через FTDI), неделю назад — reveng (подбор алгоритмов/полиномов CRC). avrdude (программатор MCU AVR) тоже так делает.
Из всего этого для линуха только avrdude попадается.
Хм. Попробовал. И впрямь. Даже и не знаю, что сказать. Всё же, большинство программ help в stdout печатают...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему изрядная часть unix-like утилит выводит справку в stderr?
Оно еще и не 0 в exit code. Если утилита участвует в pipe ты точно хочешь мусор на входе следующего этапа конвейера?
Здравствуйте, kov_serg, Вы писали:
_>когда указываете неверный ключ вам вываливают сообщение об ошибке и за одно справку.
Это тоже криво. Таки терминал предполагает, что за ним сидит не такой дилетант, как за гуем, поэтому вываливать ему полную справку на каждую ошибку — явное и грубое неуважение. Особенно, когда справка объемная, и после ее вывода сообщения об ошибке уже нет.
_>А stdout для вывода данных.
Здравствуйте, Marty, Вы писали:
ЕМ>>Такая же, как что? Что Вы называете "технологической информацией"?
M>Такая же технологическая информация, как и сообщения об ошибках. В отличие от нормального вывода результатов работы программы
Какие признаки отличают текст справки от "результатов работы программы"? Поведение типичной программы определяется ключами командной строки. Если я задаю ключ -h, то ожидаемым и желательным результатом является текст справки. Если задаю другие ключи, ожидаемые и желательные результаты работы будут другими. А сообщения об ошибках являются или не ожидаемыми, или не желательными.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Какие признаки отличают текст справки от "результатов работы программы"? Поведение типичной программы определяется ключами командной строки. Если я задаю ключ -h, то ожидаемым и желательным результатом является текст справки. Если задаю другие ключи, ожидаемые и желательные результаты работы будут другими. А сообщения об ошибках являются или не ожидаемыми, или не желательными.
Здравствуйте, Pzz, Вы писали:
Pzz>большинство программ help в stdout печатают...
Которые встроены в линукс — само собой, от них такого авангардизма вряд ли потерпели бы. Я про самопальные.
Покопал свои завалы, нашел еще несколько (все собраны под винду): cdrecord, upx, syslinux, iperf3 (этот вообще красавчик — справку вываливает в stderr, а ошибку "parameter error" — в stdout).
В пакете UnxUtils под винду так ведут себя bzip2/bunzip2, compress, gawk (возможно, таких там еще немало). Эти вроде как портировались из родных юниксовых, еще до расцвета линуксов.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Если утилита участвует в pipe ты точно хочешь мусор на входе следующего этапа конвейера? ЕМ>Что именно считать "мусором", и почему?
Все что не в формате ожидаемого потребителем.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Покопал свои завалы, нашел еще несколько (все собраны под винду): cdrecord, upx, syslinux, iperf3 (этот вообще красавчик — справку вываливает в stderr, а ошибку "parameter error" — в stdout).
cdrecord, upx, syslinux — и впрямь.
iperf3 — починили (или попатчили в Федоре).
ЕМ>В пакете UnxUtils под винду так ведут себя bzip2/bunzip2, compress, gawk (возможно, таких там еще немало). Эти вроде как портировались из родных юниксовых, еще до расцвета линуксов.
В линухе тоже.
Про bzip2 это хоть понятно: для них штатбый режим — output в stdout вываливать, и логично больше stdout ни для чего не использовать. gawk тоже, наверное, в stdout гавкает результатами обработки, а всякими справками-муравками гавкает в stderr.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему изрядная часть unix-like утилит выводит справку в stderr?
ЕМ>На это есть какие-то разумные соглашения, или просто мода такая тупая?
Unix, и его клоны — это изначально операционные системы, заточенные, в основном на обработку текста. "Всё — есть файл", "утилита делает одну работы и делает её хорошо", "для сложных задач комбинируй простые утилиты через конвееры".
Так вот в конвеер справка попадать не должна — потребитель не знает как этот текст обработать, да ещё это переносит ошибку в другое место, что затрудняет отладку. Зато он знает что делать с ненулевым кодом выхода.
Это в винде везде произвол.
Здравствуйте, Marty, Вы писали:
M>Почему тупая? По мне так — вполне логично. В stdout выдаются результаты работы программы, а всякие служебные сообщения, об ошибках там, или та же справка — в stderr
Большая часть програм, о которых мы говорим, не выдают в stdout результаты работы.
Если справка длинная — её хочется в less. Если программа выводит её в stderr, приходится вспоминать каждый раз, как stderr в stdout перенаправляется. Бесит, аж жуть.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это тоже криво. Таки терминал предполагает, что за ним сидит не такой дилетант, как за гуем, поэтому вываливать ему полную справку на каждую ошибку — явное и грубое неуважение. Особенно, когда справка объемная, и после ее вывода сообщения об ошибке уже нет.
Я обычно вываливаю полную справку если 1) пользователь не указал ни одного command-line аргумента и 2) их отсутствие является ошибкой.
Здравствуйте, Doom100500, Вы писали:
D>Так вот в конвеер справка попадать не должна — потребитель не знает как этот текст обработать
Если справка попала в конвейер, это значит, что это либо было запланировано составителем того конвейера, либо случилось что-то внеплановое (ошибка в командной строке, глюк утилиты и т.п.), а в этом случае в конвейер может попасть все, что угодно. Пытаться оправдать этим вывод справки в stderr выглядит очень коряво. Вряд ли Вы сумеете найти подобное "обоснование" от сколько-нибудь авторитетных апологетов unix way.
D>Это в винде везде произвол.
Вот как раз те консольные утилиты, что изначально писаны под винду, дружно выводят справку в stdout. Исключения очень редки. Произвол и бардак я вижу в основном среди утилит, которые пришли из unix/Linux.
Здравствуйте, Pzz, Вы писали:
Pzz>Я обычно вываливаю полную справку если 1) пользователь не указал ни одного command-line аргумента и 2) их отсутствие является ошибкой.
Я обычно так же.
Вообще, если внимательно проанализировать доводы, выдвинутые здесь сторонниками вывода справки в stderr, то все они содержат внутренние противоречия, поскольку основаны на субъективной, вкусовой интерпретации. Мне пока удалось найти лишь один объективный критерий — это ожидаемость/предсказуемость вывода. Текст справки, идущий в поток, полностью предсказуем (кроме редких утилит, которые любят вываливать различные подсказки, но в *nix это не поощряется), а по ключам -h/--help — еще и ожидаем. Для любых сообщений об ошибках нарушается или один критерий, или оба сразу.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вообще, если внимательно проанализировать доводы, выдвинутые здесь сторонниками вывода справки в stderr, то все они содержат внутренние противоречия, поскольку основаны на субъективной, вкусовой интерпретации. Мне пока удалось найти лишь один объективный критерий — это ожидаемость/предсказуемость вывода. Текст справки, идущий в поток, полностью предсказуем (кроме редких утилит, которые любят вываливать различные подсказки, но в *nix это не поощряется), а по ключам -h/--help — еще и ожидаем. Для любых сообщений об ошибках нарушается или один критерий, или оба сразу.
Меня, кстати, поразила массовость этого явления, вывода справки в stderr. Как-то я раньше даже и не знал (но многие из упомянутых тобой утилит для меня — что-то, что используется раз в три года).
Всё же, бардак всегда спутник отсутствия ценрального управления, UNIX тому — наглядный пример.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему изрядная часть unix-like утилит выводит справку в stderr? ЕМ>На это есть какие-то разумные соглашения, или просто мода такая тупая?
Вывод данных в stdout.
Логи/ошибки в stderr. В том числе и справка, если она выводится в ответ на какие-то неправильные аргументы.
Но по ключу -h/--help справка должна идти в stdout однозначно, так как это и есть результат.
Если же по ключу -h/--help выводят в stderr, то это лентяи, которым впадлу было писать выбор потока для справки, или просто недалёкие.
Вообще, выводить справку в ответ на ошибку аргументов — это дичь. Надо просто ошибку выводить. Тогда справка всегда только по запросу и всегда только в stdout.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Doom100500, Вы писали:
D>>Так вот в конвеер справка попадать не должна — потребитель не знает как этот текст обработать
ЕМ>Если справка попала в конвейер, это значит, что это либо было запланировано составителем того конвейера, либо случилось что-то внеплановое (ошибка в командной строке, глюк утилиты и т.п.), а в этом случае в конвейер может попасть все, что угодно. Пытаться оправдать этим вывод справки в stderr выглядит очень коряво. Вряд ли Вы сумеете найти подобное "обоснование" от сколько-нибудь авторитетных апологетов unix way.
Если в конвейер пихать всё, что угодно, особенно длинные тексты — это отрывает огромную дыру в безопасности таких конвейеров. Хорошей практикой считается закрывать такие дыры с обеих сторон. Поэтому тексты, для которых в кенвейере не предусмотренна обработка идут в stderr. Особенно произвольные и неформатированные тексты, которые могут меняться от версии к версии, в отличие от ожидаемого вывода.
Здравствуйте, andrey.desman, Вы писали:
AD>Логи/ошибки в stderr. В том числе и справка, если она выводится в ответ на какие-то неправильные аргументы.
То есть, когда справка является частью сообщения об ошибке, верно?
AD>Если же по ключу -h/--help выводят в stderr, то это лентяи, которым впадлу было писать выбор потока для справки, или просто недалёкие.
Я тут упоминал, что в коде встречается явное указание stderr при выводе справки, а не вываливание туда всего вывода.
AD>Вообще, выводить справку в ответ на ошибку аргументов — это дичь. Надо просто ошибку выводить. Тогда справка всегда только по запросу и всегда только в stdout.
Да, именно так. Вместе с сообщением об ошибке можно выводить подсказку — в том числе и о ключах -h/--help.
Здравствуйте, Doom100500, Вы писали:
D>Если в конвейер пихать всё, что угодно, особенно длинные тексты — это отрывает огромную дыру в безопасности таких конвейеров.
Какая еще "дыра в безопасности конвейеров", когда сама идея конвейера вообще никак не соотносится с идеей безопасности? Эта Ваша фраза — типичный пример наукообразной бессмыслицы.
D>Хорошей практикой считается закрывать такие дыры с обеих сторон.
Хорошей практикой считается не применять конвейеры и подобным им механизмы на стыках разных уровней привилегий, да и вообще везде, где требуется мало-мальски значимая ответственность. Административные скрипты, использующие конвейеры — это по определению костыль, работающий лишь до тех пор, пока обе стороны конвейера никто не трогает.
D>Поэтому тексты, для которых в кенвейере не предусмотренна обработка идут в stderr.
Вы сами-то поняли, что сказанули? Сообразите, что утверждение явно глупое, или разъяснить?
Здравствуйте, Pzz, Вы писали:
M>>Почему тупая? По мне так — вполне логично. В stdout выдаются результаты работы программы, а всякие служебные сообщения, об ошибках там, или та же справка — в stderr
Pzz>Большая часть програм, о которых мы говорим, не выдают в stdout результаты работы.
Ну. У меня сложилось впечатление, что в целом идеология такова, что если не задавать выходной файл (или задать что-то типа '-'), то результаты будут выводится в stdout, и это можно встроить в пайп.
Pzz>Если справка длинная — её хочется в less. Если программа выводит её в stderr, приходится вспоминать каждый раз, как stderr в stdout перенаправляется. Бесит, аж жуть.
Сто лет не было желания пользоваться каким-то less — по-моему терминалы сто лет как умеют прокручивать вывод, просто колёсиком мыши крутишь, и всё
Здравствуйте, Marty, Вы писали:
Pzz>>Большая часть програм, о которых мы говорим, не выдают в stdout результаты работы.
M>Ну. У меня сложилось впечатление, что в целом идеология такова, что если не задавать выходной файл (или задать что-то типа '-'), то результаты будут выводится в stdout, и это можно встроить в пайп.
А у меня сложилось впечатление, что каждый делает, как захотелось.
Pzz>>Если справка длинная — её хочется в less. Если программа выводит её в stderr, приходится вспоминать каждый раз, как stderr в stdout перенаправляется. Бесит, аж жуть.
M>Сто лет не было желания пользоваться каким-то less — по-моему терминалы сто лет как умеют прокручивать вывод, просто колёсиком мыши крутишь, и всё
До появление less был more. Он был не таким удобным, но он был примерно всегда.
Здравствуйте, Pzz, Вы писали:
Pzz>Про bzip2 это хоть понятно: для них штатбый режим — output в stdout вываливать, и логично больше stdout ни для чего не использовать. gawk тоже, наверное, в stdout гавкает результатами обработки, а всякими справками-муравками гавкает в stderr.
Я именно про эту "идеологию" и говорил
Pzz>Но cdrecord!
Просто использует устоявшиеся соглашения? Вероятно, автор решил, что если одни утилиты будут справку выводить в stderr, а другие — в stdout, то это будет, как минимум, странно и непривычно
Здравствуйте, Marty, Вы писали:
Pzz>>Но cdrecord!
M>Просто использует устоявшиеся соглашения? Вероятно, автор решил, что если одни утилиты будут справку выводить в stderr, а другие — в stdout, то это будет, как минимум, странно и непривычно
Большинство юниксных утилит выводят справку в stdout.
Наверное, в материалах GNU есть даже какой-нибудь гайд на эту тему. Но лень его искать...
Здравствуйте, Marty, Вы писали:
M>Просто использует устоявшиеся соглашения? Вероятно, автор решил, что если одни утилиты будут справку выводить в stderr, а другие — в stdout, то это будет, как минимум, странно и непривычно
GNU Coding Standard говорит, опция --help должна вываливать хелп в stdout и завершаться с кодом 0.
Здравствуйте, Pzz, Вы писали:
M>>Просто использует устоявшиеся соглашения? Вероятно, автор решил, что если одни утилиты будут справку выводить в stderr, а другие — в stdout, то это будет, как минимум, странно и непривычно
Pzz>GNU Coding Standard говорит, опция --help должна вываливать хелп в stdout и завершаться с кодом 0.
Pzz>https://www.gnu.org/prep/standards/html_node/_002d_002dhelp.html
ЕМ>>Почему изрядная часть unix-like утилит выводит справку в stderr? N>Оно еще и не 0 в exit code. Если утилита участвует в pipe ты точно хочешь мусор на входе следующего этапа конвейера?
Я точно хочу.
Во первых, возможно, именно в этом и цель (передать справку, ведь её для этого запросили явно).
Во вторых если неожиданно где-то вылезла именно справка, значит скорее всего конвейер сломался (что-то обновилось?), и по внезапной справке можно быстро определить на каком этапе.
