Правда ли, что существует 4 типа ** вывода **, мы можем ссылаться на файл в Linux?

Верно ли вы заключить, что есть 4 типа вывода потока, которые мы можем ссылаться на файл в Linux, если мы не хотим, чтобы они отображались в CLI после выполнения их команды?

Возможные ссылки на файл:

  1. Весь поток
  2. Только stderr
  3. Только stdout (включая окончательный результат stdout).
  4. stdout и stderr (исключая конечный результат stdout).

Заметки:

Пример для числа 4 может быть find / -type f -name php.ini 2>/dev/null . Как я понимаю как новичок, с этой командой мы не получаем stderr и stdout (кроме окончательного результата stdout, который в этом случае является файлом, который мы искали, если он был найден).

3 Solutions collect form web for “Правда ли, что существует 4 типа ** вывода **, мы можем ссылаться на файл в Linux?”

В Unix есть два стандартных потока вывода: стандартный вывод (stdout, файловый дескриптор 1) и стандартная ошибка (stderr, file-descriptor 2). Они могут быть перенаправлены независимо друг от друга. Стандартный ввод использует файловый дескриптор 0.

  • Чтобы перенаправить stdout в file , используйте >file или более явный 1>file . Замените file /dev/null чтобы удалить данные.
  • Чтобы перенаправить stderr в file , используйте 2>file .
  • Чтобы перенаправить stderr туда, куда идет stdout, используйте 2>&1 .
  • Чтобы перенаправить stdout туда, где происходит stderr, используйте 1>&2 .

Нет понятия конечного результата процесса. Я полагаю, что все, что отправлено в stdout, может приниматься за «результат» процесса, если оно также не выводит данные в какой-либо файл, который он открывает сам по себе, или имеет другие побочные эффекты (например, отключение файла из каталога, в случае rm или обрабатывать несколько сетевых подключений, в случае sshd ).

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

В примечании в вопросе команда

 find / -type f -name php.ini 2>/dev/null 

дано. Это перенаправляет (исключает) только stderr. Стандартный поток вывода не перенаправляется вообще и поэтому будет полностью отображаться в консоли или терминале. Если это была промежуточная часть конвейера, поток stdout будет передаваться в stdin следующей команды в конвейере.

Таким образом, я бы сказал, что есть два (не четыре) стандартных потока вывода. Они могут быть перенаправлены независимо различными способами, включая отказ от их содержимого.

Каждый процесс может, по договоренности, использовать три стандартных дескриптора файла. Эти файловые дескрипторы доступны как потоки: stdin , stdout и stderr .

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

Вы можете указать оболочке перенаправить их в другом месте, например, в /dev/null (где они просто проглатываются). И вы можете сделать это самостоятельно для stdout и stderr . Итак, для этого случая есть четыре возможности:

 command command > /dev/null command 2> /dev/null command > /dev/null 2> /dev/null 

Но ничто не мешает вам перенаправлять то или другое в другом месте:

 command > /tmp/myout 2> /tmp/myerr 

В этом случае вы также не получите выход в своем терминале, но вы можете прочитать его позже в файлах /tmp/myout и /tmp/myerr .

Ситуация проще и сложнее, чем предполагал ваш вопрос. Перефразируя то, что говорит Кусалананда в своем ответе , есть два стандартных (обычных) потока ввода-вывода (файловые дескрипторы), которые условно настраиваются и используются для вывода: stdout (дескриптор файла 1) и stderr (дескриптор файла 2). Наш канонический вопрос: каковы операторы управления и перенаправления оболочки? , обсуждает, как перенаправить их. Наивно, мы можем перечислить пять различных комбинаций:

 ╔══════════════════════════════╦═════════════════════════════════════════════╗ ║ ║ stderr ║ ║ ╟─────────────────────┬───────────────────────╢ ║ ║ default │ ║ ║ ║ (same as the shell) │ redirected ║ ╠════════╤═════════════════════╬═════════════════════╦═══════════════════════╣ ║ │ default ║ ║ ║ ║ │ (same as the shell) ║ 1 ║ 2 ║ ║ ├─────────────────────╠═════════════════════╬═══════════════════════╣ ║ stdout │ ║ ║ 4. redirected ║ ║ │ ║ ║ to the same file ║ ║ │ redirected ║ 3 ╟───────────────────────╢ ║ │ ║ ║ 5. redirected ║ ║ │ ║ ║ to different files ║ ╚════════╧═════════════════════╩═════════════════════╩═══════════════════════╝ 

но если вы считаете /dev/null отличным от файла и добавляете режим как особый случай, а режим чтения-записи отличается от режима только для записи, а трубы отличаются от файлов, то количество комбинаций экспоненциально возрастает. Однако, как неоднократно заявлялось, «окончательный результат stdout» не является стандартной фразой Unix / Linux / bash.

Только два?

Другие ответы (возможно, разумно) ограничили себя stdout и stderr (файловые дескрипторы 1 и 2). Я (безрассудно?) Считаю, что полный ответ на этот вопрос должен учитывать тот факт, что доступны другие дескрипторы файлов – до сотен, тысяч или даже более миллиона . Например, если вы запустите команду, например diff file1 file2 , программа diff откроет file1 и file2 , и ядро, вероятно, назначит файловые дескрипторы 3 и 4. Разница в том, что только дескрипторы файлов 0, 1 и 2 предварительно определены , Перенаправление файловых дескрипторов выше 2 обсуждается в следующих местах:

  • Справочное руководство Bash: раздел 3.6 «Перенаправления»
  • Advanced Bash-Scripting Guide: Глава 20. Перенаправление ввода-вывода
  • Разница между 2> & -, 2> / dev / null, | &, &> / dev / null и> / dev / null 2> & 1 (вопрос U & L)
  • Можем ли мы иметь больше дескрипторов файлов, отличных от обычных stdin / stdout / stderr (0, 1, 2)? (Вопрос переполнения стека)

Например, см. Этот пример дескриптора высокого файла:

  $ cat canine.c
 #include <stdio.h>
 #include <string.h>

 главный()
 {
         int i, len;
         char msg [] = "Привет, собака. \ n";

         len = strlen (msg);
         i = записать (17, msg, len);
         если (i == len)
                 printf («Успех! i =% d = len \ n», i);
         else if (i == -1)
             {
                 printf («Ошибка! i =% d (len =% d) \ n", i, len);
                 PError ( "");
             }
         еще
                 printf («Неожиданный результат: i =% d, len =% d \ n», i, len);
 }

 $ make собачьи
 cc canine.c -o собака

 $ ./canine
 Ошибка!  i = -1 (len = 12)
 Плохой дескриптор файла

 $ ./canine 17> животное
 Успех!  i = 12 = len

 $ ls -l
 всего 70
 -rw-r-r-- 1 myusername mygroupname 12 Apr 12 13:36 animal
 -rwxr-xr-x 1 myusername mygroupname 67067 12 апр 13:36 клын
 -rw-r - r-- 1 myusername mygroupname 358 12 апреля 13:36 canine.c

 $ cat animal
 Привет, собака. 

Предупреждение: я не уверен, что выше будет работать для всех версий всех оболочек.

Стандартные программы не записывают в дескрипторы файлов выше 2 (если только они не получили этот файловый дескриптор из ядра, открыв файл, установив сетевое соединение или что-то в этом роде). Но если у вас есть (нестандартная) программа, которая делает это, вы можете перенаправить эти файловые дескрипторы.

И если у вас всего 100 дескрипторов файлов, и вы учитываете только то, перенаправляется ли каждый из них или нет, у вас есть несколько миллионов (1,000,000,000,000,000,000,000,000,000,000) возможных комбинаций.

  • Запись на stdout, кроме перенаправления вывода C
  • Добавить вывод в файл и перенаправить stderr в null
  • Могу ли я настроить оболочку для печати STDERR и STDOUT в разных цветах?
  • Неудачное решение от «Как перенаправить stdout и stderr в файл и отобразить stderr для консоли»
  • Сценарий оболочки не отображает последнюю строку stdout на экране без ввода пользователем
  • Записать исходный файл Python в файл немедленно
  • `docker logs foo | less` не доступен для поиска или прокрутки, но `docker logs foo 2> & 1 | меньше` является
  • pipe stdout-to-file с wc
  • Создайте двухстрочный текстовый файл без записи на stdout
  • Декодирование «prog> file 2> & 1"
  • Трубы, как поток данных в трубопроводе?
  • Linux и Unix - лучшая ОС в мире.