Ошибка ввода вывода linux

Обновлено: 05.07.2024

Каждый пользователь, рано или поздно сталкивается с определенными проблемами в своей операционной системе Linux. Это может быть просто неправильное использование команд или их непонимание, так и такие серьезные ошибки Linux, как отсутствие драйверов, неработоспособность сервисов зависание системы и так далее.

Эта статья ориентирована в первую очередь на новичков, которые не знают, что делать когда их будут поджидать проблемы linux, мы дадим общую концепцию и попытаемся показать в какую сторону двигаться дальше. Мы рассмотрим исправление ошибок в linux как простых, так и более сложных. Но давайте сначала определим, какие проблемы linux будем рассматривать, разобьем их на категории:

Проблемы с командами в терминале
Проблемы с программами
Проблемы с драйверами и ядром
Проблемы с графической оболочкой
Проблемы с диском и файловой системой

Все это мы рассмотрим ниже, но сначала общее введение и немного теории.

Решение проблем Linux

Linux очень сильно отличается от WIndows, это заметно также при возникновении проблем Linux. Вот допустим, произошла ошибка в программе Windows, она полностью закрывается или выдает непонятное число с кодом ошибки и все, вы можете только догадываться или использовать поиск Google, чтобы понять что произошло. Но в Linux все совсем по-другому. Здесь каждая программа создает лог файлы, в которых мы можем при достаточном знании английского или даже без него, выяснить, что произошло. Более того, если программу запускать из терминала, то все ошибки linux и предупреждения мы увидим прямо в окне терминала. и сразу можно понять что нужно делать.

Permission Denied - нет доступа, означает что у программы нет полномочий доступа к определенному файлу или ресурсу.
File or Directory does not exist - файл или каталог не существует
No such file or Directory - нет такого файла или каталога
Not Found - Не найдено, файл или ресурс не обнаружен
Connection Refused - соединение сброшено, значит, что сервис к которому мы должны подключиться не запущен
is empty - означает, что папка или нужный файл пуст
Syntax Error - ошибка синтаксиса, обычно значит, что в конфигурационном файле или введенной команде допущена ошибка.
Fail to load - ошибка загрузки, означает что система не может загрузить определенный ресурс, модуль или библиотеку (fail to load library) обычно также система сообщает почему она не может загрузить, permission denied или no such file и т д.

Проблемы с командами в терминале

Обычно проблемы с командами в терминале возникают не из-за ошибки linux или потому, что разработчики что-то недоработали, а потому, что вы ввели что-то неправильно или предали не те что нужно опции.

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

Также довольно частой ошибкой при выполнении команд есть неиспользование команды sudo перед самой командой для предоставления ей прав суперпользователя. В таких случаях вы обычно получаете ошибку Permission Denied или просто уведомление, что не удалось открыть тот или иной файл или ресурс: can not open . can not read . и так далее.

Очень распространенной среди новичков ошибкой, есть no such file or directory при попытке выполнить файл, скачанный из интернета. Сразу кажется что это бред, ведь файл существует, но на самом деле оболочка ищет только файлы с флагом исполняемый, а поэтому пока вы не установите этот флаг для файла, он для оболочки существовать не будет.

Проблемы в программах

Если ни с того ни с сего закрывается или не так, как требуется работает, какая-нибудь графическая программа, решение проблем linux начинается из запуска ее через терминал. Для этого просто введите исполняемый файл программы и нажмите Enter. Обычно достаточно начать вводить имя программы с маленькой буквы и использовать автодополнение для завершения ввода названия.

Многие ошибки системы linux, связанные с графической оболочкой вы можете найти в файле

/.xsession-errors в вашей домашней директории. Если оболочка работает медленно, зависает или не работают другие программы, но в других логах причин этому нет, возможно, ответ находится именно в этом файле.

$ sudo systemctl status имя_сервиса

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

Здесь, как и всегда большинство ошибок связано с тем, что что-то не установлено, какого-то файла нет или к чему-то невозможно получить доступ, тогда решение проблем linux не вызовет много забот.

Проблемы с драйверами и ядром

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

Чтобы иметь возможность удобно листать вывод можно выполнить:

sudo dmesg | less

Или сразу выбрать все ошибки:

sudo dmesg | grep error

Проблемы с графической оболочкой

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

При проблемах с графической оболочкой вы можете всегда переключиться в режим терминала с помощью сочетания клавиш Ctrl+Alt+F1. Далее, вам нужно ввести логин и пароль, затем можете вводить команды терминала.

Посмотреть логи графической оболочки вы можете в том же файле

Если проблема наблюдается после обновления до новой версии, то можно очистить кеш и удалить папку с настройками, обычно это помогает.

Проблемы с диском и файловой системой

Самая частая проблема с диском у новичков - это переполнение диска. Если под диск выделить очень мало места, то он переполнится и система не сможет создавать даже временные файлы, а это приведет к тому что все если не зависнет, то, по крайней мере, не сможет нормально работать.

Если это случилось, вам, скорее всего, придется переключиться в режим терминала и удалить несколько файлов. Вы можете удалять файлы логов или кэша пакетного менеджера. Много файлов удалять не нужно, достаточно освободить несколько мегабайт, чтобы прекратились ошибки системы linux и нормально работала графическая оболочка, а затем уже в ней решать все проблемы linux.

Выводы

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

Я хочу перечислить и удалить содержимое каталога на съемном жестком диске. Но я испытал «Ошибка ввода / вывода»:

Мне было интересно, в чем проблема?

Как я могу восстановить или удалить каталог pic и все его содержимое?

Моя ОС - Ubuntu 12.04, а съемный жесткий диск имеет файловую систему ntfs. Другие каталоги, не содержащие или не находящиеся pic на съемном жестком диске, работают нормально.

Последняя часть вывода dmesg после того, как я попытался перечислить содержимое каталога:

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

Ошибки ввода / вывода при попытках доступа к файловой системе обычно означают аппаратные проблемы.

Введите dmesg и проверьте последние несколько строк вывода. Если диск или подключение к нему не удается, это будет отмечено там.

РЕДАКТИРОВАТЬ Вы монтируете его через ntfs или ntfs-3g ? Насколько я помню, устаревший ntfs драйвер не имел поддержки стабильной записи и был в основном заброшен, когда оказалось, что ntfs-3g он значительно более стабилен и безопасен.

Я подключаю съемный жесткий диск к своей Ubuntu 12.04, и он автоматически монтируется. Так я думаю ntfs-3g ? Не " угадай ". Проверьте - вы можете увидеть, как все монтируется, набрав mount команду и глядя на вывод. (1) Я добавил последнюю часть вывода dmesg после того, как попытался составить список содержимого каталога. Я не знаю, как это помогает. (2) Я не могу увидеть, смонтирован ли он с помощью nfts-3g или ntfs, посмотрев на вывод mount : /dev/sdb1 on /media/removable_drive type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096) fuseblk означает, что он использует метод fuser файловая система в пользовательском пространстве, что и ntfs-3g используется. Так что ты хорош в этом отношении.

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

Вы можете выполнить сканирование поверхности вашего диска из Linux /sbin/badblocks /dev/sda .

Проверьте страницу руководства для более тщательного тестирования основных исправлений (перемещение блоков). Все это не зависит от файловой системы, поэтому является безопасным даже для файловой системы NTFS, поскольку работает на уровне «поверхности диска».

Я лично сделал это для запуска ежемесячно от cron. Конечно, вам нужно проверить, получаете ли вы письма cron в своем почтовом ящике (что по умолчанию часто не так). Эти письма заканчиваются /var/mail/$USER или похожи.

Я создал /etc/cron.d/badblocks :

Спасибо! Для запуска команды, которую вы предложили, это /sbin/badblocks /media/removable_drive в моем случае? Нет. Согласно выводу dmesg вы должны использовать sdb: /sbin/badblocks /dev/sdb или sdc. Я действительно не могу понять, что случилось / вы сделали dmesg Вы можете найти свой /dev/sd диск с fdisk -l командой помните, что приложение badblocks принимает блоки начала и конца для работы в случае, если вы хотите «приостановить / возобновить» :)

Ваша файловая система повреждена, для томов NTFS вы должны запустить систему chkdsk под Windows, но восстановить ее практически невозможно. Иногда вам может понадобиться отформатировать диск.

Спасибо! Мои другие каталоги в порядке. Могу ли я не отформатировать весь диск, просто освободить место в каталоге? @ Тим, тебе пришлось скопировать все остальное, отформатировать и скопировать их обратно . я не знаю, можно ли удалить один узел . не знаком со структурой NTFS Перед форматированием попробуйте badblocks комманду в Linux.

Решение, которое работает для меня, - понизить ntfs-3g версию с выпуска 2014 года до выпуска 2012 года. Это должно решить вашу проблему с доступом к разделу NTFS. В долгосрочной перспективе это не решение, потому что в конечном итоге вам потребуется запустить последнюю версию.

Хорошо, это хорошо знать. Таким образом, в основном существует окно между 2012 и началом 2016 года, в течение которого привод просто не работал.

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

Никто не упомянул, что делать, если инструменты Linux не работают и доступен только Mac, но не Windows.

Может быть исправлено в OS X с Paragon NTFS

В моем случае gparted сказали пойти найти ПК с Windows, который нигде не было найдено. Но рядом был Mac, для которого доступно это замечательное программное обеспечение. Установил пробную версию, выполнил проверку , затем чинил - и вуаля!

У меня был случай на macos, когда такая ошибка была вызвана использованием sshfs (вроде бы) в сборке инструментария. Помогла установка osxfuse & sshfs через brew.

Я просто хотел поделиться своим опытом: во FreeBSD 10.3 я подключил свой внешний жесткий диск с

Внутри жесткого диска я mkdir создал папку, а затем переместил в нее несколько файлов, конечно, с помощью mv команды. Наконец я выполнил следующую команду:

Я не смог избавиться от Jeff каталога на машине с Linux, поэтому я использовал машину с FreeBSD и снова смонтировал жесткий диск на FreeBSD. Но ls , cd и rm команды на FreeBSD генерировать то же самое Input/output error . Похоже, в ntfs-3g пакете FreeBSD была ошибка .

ОБНОВИТЬ

Я перенес все свои данные с внешнего жесткого диска на компьютер с Linux, конечно, поврежденный файл Jeff не мог быть перемещен из-за ошибки ввода-вывода. Затем я переформатировал внешний жесткий диск с обнулением тома и проверкой сбойного сектора следующим образом:

А затем переместил все данные обратно на внешний том. Таким образом, я потерял поврежденный файл с именем Jeff , однако мой внешний жесткий диск очищен от любых ошибок ввода-вывода.

Я объявил, что когда я пытаюсь получить доступ к диску, на котором возникла эта ошибка, он пытался записать последние скопированные файлы, которые были перезаписаны в последний файл, а затем попытка доступа не удалась, потому что уже записанная запись не совпадает с последними скопированными элементами, поэтому происходит сбой. Самый здоровый способ спасти диск - удалить последний элемент или элементы, скопированные в Windows.

Доброго времени суток! Есть жесткий диск на 3тб, который стоял в каком-то NAS от D-Link. Диск работал, потом попробовали воткнуть в Synology, который при попытке форматнуть диск выдал ошибку. Теперь диск форматнуть не получается. Gparted не видит таблицу разделов. При попытке определить диск выдает:

Ошибка синхронизации или закрытия файлов /dev/sdb: Ошибка ввода/вывода

При попытке выполнить

В файлик падает все подряд: 0,1,2,3. При попытке выполнить

Есть какие-нибудь идеи или это труп? Диск относительно свежий, год ему. Данные мне не нужны, а вот диск - напротив.

Найди в dmesg записи про этот диск. Если они затёрлись надо будет передёрнуть диск.

$ dmesg | grep sdb

2745.611235 blk_update_request: I/O error, dev sdb, sector 0

2746.867197 blk_update_request: I/O error, dev sdb, sector 0 2746.867200 Buffer I/O error on dev sdb, logical block 0, lost async page write

2832.256882 blk_update_request: I/O error, dev sdb, sector 0

2832.256885 Buffer I/O error on dev sdb, logical block 0, async page read

2832.304945 blk_update_request: I/O error, dev sdb, sector 24

2832.304948 Buffer I/O error on dev sdb, logical block 3, async page read

2832.400881 sdb: unable to read partition table

Прошу прощения, спойлер почему-то не работает. Вот вывод sudo hdparm -I /dev/sdb:

Security:
Master password revision code = 65534
supported
enabled
locked
not frozen
not expired: security count
supported: enhanced erase
Security level high

Меня смущают эти строки. Может пасс стоит на нем?

Доброго времени суток! Упал с 3-го этажа, теперь идёт кровь из ног, торчат какие-то белые штуки, при попытке встать теряю сознание. Дополз до 3-го этажа и упал заново - не помогает. Дополз до другого здания и ещё раз упал с 3-го этажа - симптомы те же.

P.S. man dmesg и man smartctl

Очень забавно, однако диска не было у меня до сегодняшнего дня. И все манипуляции с насами не Я выполнял.

P.S. Я неправильно вывод dmesg посмотрел?

У меня нет на руках этих насов. В smartctl тоже ошибки, тесты не выполняет. В общем труп, судя по всему. Спасибо всем, за уделенное время.

Не надо тесты выполнять (и так понятно, что они не пройдут), надо попробовать посмотреть smartctl -A /dev/sdX

Опишем окружение в котором возникла ошибка ввода/вывода:

ОС: Linux совместно с Windows
HDD: два диска, на одном Windows XP (далее ДИСК 1 ), на другом Linux Debian 7.x (далее ДИСК 2 )

Каждый диск разбит на два раздела, - на диске с Windows XP два раздела с файловой системой NTFS, на втором диске с Linux Debian 7.x один раздел EXT4, на котором и установлен Linux, а на втором собственно NTFS. Окружением для рабочего стола Linux было выбрано Xfce, файловый менеджер по умолчанию Thunar 1.2.3 (Thunar это быстрый и простой в использовании файловый менеджер для рабочего окружения Xfce.), текстовый редактор gedit.

Ошибка ввода/вывода появилась на ДИСК 2 в разделе с файловой системой NTFS, который монтировался вручную после входа в уч. запись Linux.

Когда именно появилась Ошибка ввода/вывода на NTFS разделе сказать сложно, но предположительно после очередного переключения между ОС. На ДИСК 2 были расположены совместно редактируемые файлы, - т.е. эти фалы (Test.txt один из них) были открыты в текстовом редакторе notepad++ под ОС Windows XP и в текстовом редакторе gedit под Linux Debian 7.x. Перед переключением между ОС каждая ОС переводилась в спящий режим с сохранением запущенных программ и открытых файлов.

Не скажу, как и почему стала появляться Ошибка ввода/вывода, - возможно gedit попутал uid/gid (файловые/индексные дескрипторы) и при сохранении в Master File Table (MFT) прописал не то, не тем и не туда, но вот, что получилось после очередного переключения между ОС при совместном редактировании файлов:

Попытка открыть каталог " /media/SATA2/PROFILE/User/Рабочий стол " в Thunar:

Остальное содержимое каталога было не доступно для просмотра/редактирования

Попытка сохранить уже открытый в gedit текстовый файл Test.txt :

При использовании файлового менеджера NAUTILUS удалось открыть каталог /media/SATA2/PROFILE/User/Рабочий стол и удалить " Test.txt ", но вот создать заново Test.txt или создать «Безымянный документ» и переименовать его в «Test.txt» не удалось:

Следующий глюк сопутствовал Ошибкам ввода/вывода, но вот при каких условиях возник не припомню (вероятно при нескольких одновременных попытках монтирования):

Владелец и права на файл Test.txt не известны:

В некоторых манах для лечения предлагалось использовать ntfsfix -b /dev/sdb5 , предварительно отмонтировав его, - но проблема не решилась.

В среде Linux на ДИСК 2 были созданы текстовые файлы " Test_2.txt " и " Test_3.txt " и совершено переключение на Windows XP где эти файлы были не доступны даже для просмотра, хотя после перехода обратно в Linux их можно было просматривать и редактировать.

Проблему с косяком в NTFS разделе на ДИСК 2 удалось решить только с помощью стандартного средства проверки дисков входящего в ОС Windows XP в процессе перезагрузки:

Увидев на экране Deleting index entry . я зразу же понял, что этих файлов нам уже не видать как своих ушей, - разумеется, так и есть.

Существует также ещё один способ монтирования NTFS с возможностью чтения/записи, - это Проект NTFS-3G, который по заявлениям является более функциональным и стабильным вариантом (также использующий FUSE) дающий более широкие возможности по созданию/изменению/удалению/перемещению файлов (исключая сжатые и зашифрованные файлы) в файловой системе NTFS. В тоже время тесты показывают, что NTFS-3G не оптимизирован для производительности, а разработчики заявляют, что это связано с обеспечением повышенной надёжности и, что производительность является второстепенной задачей.

Никто не застрахован от возникновения каких-то ошибок на разделах с файловой системой NTFS или же вовсе полного краха таких разделов с необходимостью полного форматирования. Поэтому, при использовании Linux лучше вовсе не использовать NTFS разделов, или же использовать их как можно реже.

Основные причины ошибок ввода/вывода

Значит это всё масонский заговор дядюшки Билла. На буржуйских веб-ресурсах бродит информация о том, что стандарт NTFS меняется в каждой новой версии Windows, что вполне предсказуемо, включая сервис-паки и промежуточные патчи. При этом, разумеется, изменения не придаются общественной огласке, а следовательно нет возможности в полной мере обеспечить стабильную работу с NTFS в свободных ОС таких как Linux.
Отмечено также, что на разделах NTFS возможно изменение уже существующих файлов с незначительным изменением их размера, но при создании новых файлов или существенного изменения уже существующих может вызвать проблемы и даже "запороть" весь раздел.
Проблемы с отображением созданных в Linux на NTFS разделе файлов, а также проблемы с ошибками ввода/вывода, могут возникнуть если на ПК установлено несколько ОС (ака Мультизагрузка, Multi-boot), - Windows vs Linux. Пик ошибок ввода/вывода отмечен когда Windows была переведена в спящий режим, а после очередного включения запущен Linux из-под которого на NTFS разделе создавались/редактировались файлы. Другими словами если мы хотим из-под ОС Linux, в условиях мультизагрузки (Multi-boot), относительно безопасно создавать/редактировать файлы на NTFS разделах совместно используемых обеими ОС, то перед запуском ОС Linux мы должны выполнить полную перезагрузку или остановку ОС Windows, но не в коем случае не переводить Windows в спящий режим!
SRT-кэширование (Smart Response Technology) - ещё одна "фича", которая может стать причиной невидимости из-под Windows на NTFS разделах файлов, которые создавались в Linux. Предположительно Linux не поддерживает SRT-кэширование (касается только SSD дисков), которое поддерживает Windows, а значит при создании из-под Linux-а файлов на SSD дисках с активным SRT-кэширование кэш не обновляется и после загрузки Windows файлов не обнаруживается. Предлагается отключить SRT-кэширование для SSD диска.

Тема использования NTFS в Linux является довольно актуальной, требует более подробного изучения и дополнительных экспериментов. О появлении новых багов, в ходе использования NTFS разделов в Linux, и, способов их решения, - будем дописывать в этой же статье.

Stdin, stdout и stderr

Когда вы запускаете команду Linux, в ней играют роль три потока данных:

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

Думайте об этом как о струе воды. Вам нужен источник для воды, например, кран. Вы подключаете к нему трубу и можете хранить ее в ведре (файле) или поливать растения (распечатывать). Вы также можете подключить его к другому крану, если это необходимо. По сути, вы перенаправляете воду.

Позвольте нам показать, как работает перенаправление и как вы можете его использовать.

Перенаправление вывода

Первой и самой простой формой перенаправления является перенаправление вывода, также называемое перенаправлением stdout.

Вы уже знаете, что по умолчанию вывод команды отображается на экране. Например, мы используем команду ls для вывода списка всех файлов, и это вывод, который мы получаем:

Например, позвольте нам сохранить вывод команды ls в файл с именем output.txt:

Выходной файл создается заранее

Как вы думаете, каким должно быть содержимое этого выходного файла? Позвольте нам использовать команду cat, чтобы показать вам сюрприз:

Вы заметили, что включение output.txt существует ? Мы сознательно выбрали этот пример, чтобы показать вам это.

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

Добавить вместо удаления

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

Вы можете добавить вместо перезаписи, используя >> синтаксис перенаправления.

Вы можете запретить забивание в текущем сеансе оболочки, используя: set -C

Зачем вам перенаправлять стандартный вывод? Вы можете сохранить выходные данные для дальнейшего использования и проанализировать их позже. Это особенно полезно, когда вывод команды слишком велик и занимает весь экран. Это как собирать бревна.

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

Прежде чем вы увидите перенаправление stdin, вы должны узнать о перенаправлении канала. Это более распространено, и, вероятно, вы будете часто его использовать.

При перенаправлении канала стандартный вывод команды отправляется на стандартный ввод другой команды.

Позвольте нам показать вам практический пример. Скажем, вы хотите посчитать количество видимых файлов в текущем каталоге. Вы можете использовать ls -1 (это цифра один, а не буква L) для отображения файлов в текущем каталоге:

Вы, наверное, уже знаете, что команда wc используется для подсчета количества строк в файле . Если вы объедините обе эти команды с конвейером, вот что вы получите:

При использовании pipe обе команды совместно используют один и тот же буфер памяти. Вывод первой команды сохраняется в буфере, и этот же буфер затем используется в качестве ввода для следующей команды.

Вы увидите результат последней команды в конвейере. Это очевидно, потому что вывод предыдущей команды (команд) подается на следующую команду (команды) вместо перехода на экран.

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

Помните, что stdout/stdin это кусок данных, а не имена файлов

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

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

Читать Установите и используйте Hex-редактор в Kali Linux 2020

Вот почему вы часто будете видеть команду find, используемую в сопряжении с командой exec или xargs. Эти специальные команды «преобразуют текст с кучей имен файлов в имя файла», которые могут быть переданы в качестве аргумента.

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

Вы можете использовать перенаправление stdin для передачи содержимого текстового файла команде, подобной этой:

Вы не увидите, что stdin часто используется. Это потому, что большинство команд Linux принимают имена файлов в качестве аргумента и, следовательно, перенаправление stdin часто не требуется.

Возьмите это к примеру:

Приведенная выше команда могла быть просто заголовком filename.txt (без <).

Дело не в том, что перенаправление stdin совершенно бесполезно. Некоторые команды полагаются на это. Возьмите команду tr, например. Эта команда может многое, но в приведенном ниже примере она преобразует входной текст из нижнего в верхний регистр:

На самом деле, использование stdin рекомендуется по конвейеру, чтобы избежать ненужного использования команды cat.

Например, многие люди используют приведенный выше пример с cat, а затем используют tr на нем. Честно говоря, здесь нет необходимости использовать cat.

Объединить перенаправления

Вы можете комбинировать перенаправление stdin, stdout и pipe в соответствии с вашими потребностями.

Например, приведенная ниже команда перечисляет все файлы .txt в текущем каталоге, а затем подсчитывает эти файлы .txt и сохраняет выходные данные в новый файл.

Перенаправление ошибок

Но как вы различаете stdout и stderr, когда они оба являются потоком выходных данных? По их идентификатору потока (также называется дескриптором файла).

Поток данных	Идентификатор потока
stdin
stdout	1
stderr	2

По умолчанию, когда вы используете выходной символ перенаправления >, это фактически означает 1>. Словом, вы говорите, что здесь выводится поток данных с ID 1.

Примеры перенаправления Stderr

Позвольте нам показать вам несколько примеров. Предположим, вы просто хотите сохранить ошибку, вы можете использовать что-то вроде этого:

Это было просто. Давайте сделаем это немного более сложным (и полезным):

В приведенном ниже примере мы сначала отправляем stderr (с 2 >>) в файл комбинированный .txt в режиме добавления. Затем стандартный вывод (с >>) отправляется в тот же файл в режиме добавления.

Давайте возьмем предыдущий пример и на этот раз используем 2>&1 для перенаправления как stdout, так и stderr в один и тот же файл.

Имейте в виду, что вы не можете использовать 2>>&1, думая об использовании его в режиме добавления. 2>&1 уже переходит в режим добавления.

Резюме

Есть три потока данных. Один вход, stdin (0) и два потока выходных данных stdout (1) и stderr (2).
Клавиатура является стандартным устройством ввода, а экран является устройством вывода по умолчанию.
Перенаправление вывода используется с > или >> (для режима добавления).
Перенаправление ввода используется с <.
Stderr может быть перенаправлен с помощью 2> или 2>>.
Stderr и stdout можно комбинировать, используя 2>&1.

Надеюсь, вам понравилось эта подробная статья по перенаправлению в Linux. Если у вас все еще есть сомнения или у вас есть предложения по улучшению этой статьи, сообщите нам об этом в разделе комментариев.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте также: