Смущены stdin, stdout и stderr?

Я довольно запутался с целью этих трех файлов. Если я правильно понимаю, stdinэто файл, в который программа записывает свои запросы на выполнение задачи в процессе, stdoutэто файл, в который ядро ​​записывает свои выходные данные, и процесс, запрашивающий его, получает доступ к информации и stderrявляется ли этот файл в которые все исключения введены. Открыв эти файлы, чтобы проверить, действительно ли они происходят, я не нашел ничего, что могло бы предложить это!

То, что я хотел бы знать, какова цель этих файлов, абсолютно тупой ответ с очень небольшим техническим жаргоном!

Стандартный ввод - это дескриптор файла, который ваш процесс читает, чтобы получить информацию от вас.

Стандартный вывод - ваш процесс записывает обычную информацию в этот дескриптор файла.

Стандартная ошибка - ваш процесс записывает информацию об ошибке в этот дескриптор файла.

Это настолько глупо, насколько я могу это сделать :-)

Конечно, это в основном по соглашению. Ничто не мешает вам записать информацию об ошибках в стандартный вывод, если хотите. Вы даже можете полностью закрыть три файловых дескриптора и открыть свои собственные файлы для ввода / вывода.

Когда ваш процесс запускается, у него уже должны быть открыты эти маркеры, и он может просто читать и / или записывать их.

По умолчанию они, вероятно, подключены к вашему оконечному устройству (например, /dev/tty), но оболочки позволят вам установить соединения между этими дескрипторами и конкретными файлами и / или устройствами (или даже конвейерами к другим процессам) до запуска вашего процесса (некоторые из возможные манипуляции довольно умны).

Примером является:

my_prog <inputfile 2>errorfile | grep XYZ

который будет:

• создать процесс для my_prog.
• открыть inputfileкак ваш стандартный ввод (дескриптор файла 0).
• открыть errorfileкак стандартную ошибку (дескриптор файла 2).
• создать еще один процесс для grep.
• присоедините стандартный вывод my_progк стандартному входу grep.

Re ваш комментарий:

Когда я открываю эти файлы в папке / dev, почему мне никогда не удается увидеть результаты запущенного процесса?

Это потому что они не нормальные файлы. В то время как UNIX представляет все как файл в файловой системе где-то, это не делает это на самых низких уровнях. Большинство файлов в /devиерархии являются символьными или блочными устройствами, фактически драйвером устройства. У них нет размера, но у них есть старший и младший номер устройства.

Когда вы открываете их, вы подключаетесь к драйверу устройства, а не к физическому файлу, и драйвер устройства достаточно умен, чтобы знать, что отдельные процессы должны обрабатываться отдельно.

То же самое верно для /procфайловой системы Linux . Это не настоящие файлы, это просто строго контролируемые шлюзы с информацией о ядре.

Было бы правильнее сказать , что stdin, stdoutи stderrявляются «I / O потоков» , а не файлы. Как вы заметили, эти сущности не живут в файловой системе. Но философия Unix, что касается ввода / вывода, заключается в том, что «все это файл». На практике, это действительно означает , что вы можете использовать одни и те же функции библиотеки и интерфейсы ( printf, scanf, read, write, selectи т.д.) , не заботясь о том , подключен ли поток ввода / вывода с клавиатуры, дисковый файл, сокет, труба, или какая-то другая абстракция ввода / вывода.

Большинство программ должны читать ввод, вывод записи и ошибки журнала, так stdin, stdoutи stderrпредопределены для вас, для удобства программирования. Это всего лишь соглашение и не применяется операционной системой.

В качестве дополнения к ответам, приведенным выше, ниже приводится сводная информация о перенаправлениях:

РЕДАКТИРОВАТЬ: эта графика не совсем правильно, но я не уверен, почему ...

На рисунке написано, что 2> & 1 имеет тот же эффект, что и &> однако

ls Documents ABC > dirlist 2>&1
#does not give the same output as 
ls Documents ABC > dirlist &>

Я боюсь, что ваше понимание полностью назад. :)

Думайте о «стандартном входе», «стандартном выходе» и «стандартной ошибке» с точки зрения программы , а не с точки зрения ядра.

Когда программе нужно распечатать вывод, она обычно печатает в «стандартный вывод». Программа обычно печатает вывод на стандартный вывод printf, который печатает ТОЛЬКО на стандартный вывод.

Когда программе необходимо напечатать информацию об ошибке (не обязательно исключения, это конструкция языка программирования, наложенная на гораздо более высокий уровень), она обычно печатает до «стандартной ошибки». Обычно это делается с помощью fprintf, который принимает файловый поток для использования при печати. Файловым потоком может быть любой файл, открытый для записи: стандартный вывод, стандартная ошибка или любой другой файл, открытый с помощью fopenили fdopen.

«Стандартный вход» используется, когда файл должен прочитать ввод, используя freadили fgets, или getchar.

Любой из этих файлов может быть легко перенаправлен из оболочки, например так:

cat /etc/passwd > /tmp/out     # redirect cat's standard out to /tmp/foo
cat /nonexistant 2> /tmp/err   # redirect cat's standard error to /tmp/error
cat < /etc/passwd              # redirect cat's standard input to /etc/passwd

Или вся энчилада

cat < /etc/passwd > /tmp/out 2> /tmp/err

Есть два важных предостережения: во-первых, «стандартный вход», «стандартный выход» и «стандартная ошибка» - это просто соглашение. Это очень строгое соглашение, но это всего лишь соглашение о том, что очень приятно иметь возможность запускать программы, подобные этой: grep echo /etc/services | awk '{print $2;}' | sortи иметь стандартные выходные данные каждой программы, подключенные к стандартному входу следующей программы в конвейере.

Во-вторых, я дал стандартные функции ISO C для работы с файловыми потоками ( FILE *объектами) - на уровне ядра это все файловые дескрипторы ( intссылки на таблицу файлов) и много операций более низкого уровня, таких как readи write, которые не сделайте счастливую буферизацию функций ISO C. Я решил сделать это простым и использовать более простые функции, но я все же подумал, что вы должны знать альтернативы. :)

STDIN

Читает ввод через консоль (например, ввод с клавиатуры). Используется в C с scanf

scanf(<formatstring>,<pointer to storage> ...);

стандартный вывод

Производит вывод на консоль. Используется в C с printf

printf(<string>, <values to print> ...);

STDERR

Выводит ошибку на консоль. Используется в C с fprintf

fprintf(stderr, <string>, <values to print> ...);

Перенаправление

Источник для stdin может быть перенаправлен. Например, вместо ввода с клавиатуры это может быть файл ( echo < file.txt) или другая программа ( ps | grep <userid>).

Направления для stdout, stderr также могут быть перенаправлены. Например, stdout может быть перенаправлен в файл: ls . > ls-output.txtв этом случае вывод записывается в файл ls-output.txt. Stderr может быть перенаправлен с 2>.

Я думаю, что люди, говорящие, stderrдолжны использоваться только для сообщений об ошибках, вводят в заблуждение.

Его также следует использовать для информативных сообщений, предназначенных для пользователя, выполняющего команду, а не для любых потенциальных нижестоящих потребителей данных (т. Е. Если вы запускаете конвейер оболочки, объединяющий несколько команд, вам не нужны информативные сообщения, такие как «получение элемента 30 42424 ", stdoutпотому что они могут запутать потребителя, но вы все равно хотите, чтобы пользователь их увидел.

Смотрите это для исторического обоснования:

«Все программы помещали диагностику на стандартный вывод. Это всегда вызывало проблемы, когда вывод перенаправлялся в файл, но становилось невыносимым, когда вывод отправлялся в ничего не подозревающий процесс. Тем не менее, не желая нарушать простоту стандартного ввода-вывода. стандартная модель вывода, люди терпели такое положение вещей до версии 6. Вскоре после этого Деннис Ритчи разорвал узел Гордиана, введя стандартный файл ошибок. Этого было недостаточно. С помощью конвейеров диагностика могла выполняться из любой из нескольких программ, работающих одновременно. Необходима диагностика идентифицировать себя ".

Использование ps -aux показывает текущие процессы, все из которых перечислены в / proc / as / proc / (pid) /, вызывая cat / proc / (pid) / fd / 0, он печатает все, что найдено в стандартном выводе этот процесс я думаю. Так что, возможно,

/ proc / (pid) / fd / 0 - стандартный файл вывода
/ proc / (pid) / fd / 1 - стандартный файл ввода
/ proc / (pid) / fd / 2 - файл стандартной ошибки

например

Но это работало только для / bin / bash, другие процессы вообще не имели ничего в 0, но многие имели ошибки, записанные в 2

Для получения достоверной информации об этих файлах обратитесь к справочным страницам, запустите команду на своем терминале.

$ man stdout 

Но для простого ответа каждый файл предназначен для:

стандартный поток для выхода

стандартный ввод потока

stderr для печати ошибок или сообщений журнала.

Каждая программа Unix имеет каждый из этих потоков.

stderr не будет выполнять буферизацию IO Cache, поэтому, если нашему приложению нужно вывести критическую информацию о сообщении (некоторые ошибки, исключения) на консоль или в файл, используйте ее, где, как и stdout, для печати общей информации журнала, так как она использует буферизацию IO Cache, есть вероятность, что перед записью наших сообщений в файл приложение может закрыться, оставив комплекс отладки

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

https://www.mkssoftware.com/docs/man5/stdio.5.asp