Плутати про 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.

Повторіть свій коментар:

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

Це тому, що вони не нормальні файли. Хоча UNIX десь представляє все як файл у файловій системі, це не робить його на найнижчих рівнях. Більшість файлів в /devієрархії - це або символьні, або блокові пристрої, фактично драйвер пристрою. Вони не мають розміру, але вони мають основний та незначний номер пристрою.

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

Те саме стосується /procфайлової системи Linux . Це не справжні файли, а чітко контрольовані шлюзи для інформації ядра.

Правильніше було б сказати, що stdin, stdoutі stderrє "потоками вводу / виводу", а не файлами. Як ви помітили, ці об'єкти не живуть у файловій системі. Але філософія Unix, що стосується вводу-виводу, - це "все - файл". На практиці, це дійсно означає , що ви можете використовувати одні і ті ж функції бібліотеки і інтерфейси ( printf, scanf, read, write, selectі т.д.) , не піклуючись про те , чи підключений потік введення / виводу з клавіатури, дисковий файл, сокет, труба, або якась інша абстракція вводу / виводу.

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

Як доповнення до вищезазначених відповідей, ось підсумок про перенаправлення:

EDIT: Ця графіка не зовсім коректна, але я не впевнений, чому ...

Графіка говорить, що 2> & 1 має такий же ефект, як і>

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

Я боюсь, що ваше розуміння повністю відстало. :)

Подумайте про "стандартний", "стандартний вихід" та "стандартну помилку" з точки зору програми , а не з точки зору ядра.

Коли програмі потрібно надрукувати вихід, вона зазвичай друкується на «стандартне виведення». Програма, як правило, друкує вихід на стандартний з printf, який друкує ТОЛЬКО для стандартного виведення.

Коли програмі потрібно друкувати інформацію про помилки (не обов'язково винятки, це конструкція мови програмування, накладена на набагато більш високий рівень), вона зазвичай друкує до "стандартної помилки". Зазвичай це робиться за допомогою fprintf, який приймає потік файлів для використання під час друку. Потоком файлу може бути будь-який файл, відкритий для запису: стандартний вихід, стандартна помилка або будь-який інший файл, відкритий за допомогою fopenабо fdopen.

"standard in" використовується, коли файлу потрібно читати вхід, використовуючи 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

Читає вхід через консоль (наприклад, введення з клавіатури). Використовується в С із scanf

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

stdout

Виробляє вихід на консоль. Використовується в 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оскільки вони будуть бентежити споживача, але ви, можливо, все ще хочете, щоб користувач їх бачив.

Дивіться це для історичного обгрунтування:

"Усі програми розміщували діагностику на стандартному виході. Це завжди спричиняло проблеми, коли вихід був перенаправлений у фільтр, але ставав нестерпним, коли вихід був відправлений у нічого не підозрювальному процесі. Тим не менш, не бажаючи порушувати простоту стандартного входу, стандартна модель виводу, люди терпіли такий стан справ через v6. Незабаром після цього Денніс Річі розрізав Гордіїв вузол, ввівши стандартний фільтр помилок. Це було недостатньо. Завдяки діагностиці трубопроводів можна отримати будь-яку з декількох програм, що працюють одночасно. Потрібна діагностика ідентифікувати себе ».

Використання 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 

Але для простої відповіді кожен файл призначений для:

stdout для витікання

stdin для введення потоку

stderr для друку помилок або повідомлень журналу.

Кожна програма Unix має кожен з цих потоків.

stderr не буде виконувати буферизацію кеш-пам’яті IO, тому якщо нашій програмі потрібно буде надрукувати інформацію про критичне повідомлення (деякі помилки, винятки) для консолі або подати файл, де використовувати як stdout для друку загальної інформації журналу, оскільки вона використовує буферизацію кешу IO, є ймовірність, що перед тим, як писати наші повідомлення у файлову програму, може закритися, залишаючи налагодження складним

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

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