Почему я получаю сообщение об ошибке [Broken pipe]?
Может быть поучительно выяснить, почему ваша система в большей или меньшей степени «сломана».
- Как указывает @basile -starynkevitch, система управления пакетами может сильно запутаться, если найдет двоичные файлы в
/bin, хотя они должны быть в/usr/bin, и наоборот. - Некоторые (потенциально важные )сценарии могут быть жестко -подключены для поиска определенного двоичного файла в том или ином каталоге (в некоторых обстоятельствах это является хорошей практикой, например, с точки зрения безопасности, не полагаться на содержание
$PATH). - Причина, по которой существует различие между
/binи/usr/bin, заключается в том, что первый потенциально может находиться на разделе, который монтируется на более ранней стадии загрузки. В этом контексте (, то есть при загрузке системы ), не только/bin/xxxдвоичные файлы, вероятно, будут указаны полным путем, но и каталог/usr/binможет быть недоступен в системе в этот момент. (Если выdf /binиdf /usr/bin, вы можете увидеть в списке одну и ту же файловую систему или разные; вероятно, большинство установок по умолчанию в наши дни оставляют оба каталога в одном разделе ).
Таким образом, вы можете увидеть, что если у вас есть одинаковые двоичные файлы как в /bin, так и в /usr/bin, то проблемы 2 и 3 не возникнут, а ущерб от 1 может быть незначительным.. Re 1, например,пакеты могут быть удалены некорректно, если вы попытаетесь их удалить; и обновления могут быть искажены, если обновление пытается обновить копию в «правильном» месте, но игнорирует копию в «неправильном» месте. Таким образом, если приведенные выше меры кажутся слишком радикальными или сложными, вы можете уйти, оставив систему в таком состоянии.
Но если это важная система, я действительно не стал бы на это рассчитывать.
Общее правило (, снова вторящее @basile -starynkevitch )— никогда не баловаться с /usr/bin, /binи друзьями — они «принадлежат» к дистрибутиву — и пакет, который предлагает это делать как часть его обычной установки... не очень хороший пакет.
Редактировать:Относится к пункту 3, есть обсуждение в контексте systemd/Fedora и друзей о том, почему имеет смысл переместить все содержимое /binв /usr/bin, и символическая ссылка первого на второе. Это не рекомендация, что вы должны сделать это сами — эта страница адресована людям, которые занимаются распространением — но она включает в себя некоторую историю того, почему существует это различие (и, косвенно, почему теперь оно просто пыльная традиция ).
В программе на Python вы получаете сообщение об ошибке «сломан канал», поскольку вы не читаете данные, выдаваемые ею. Ваша программа на C полностью игнорирует свой стандартный входной поток, и поток закрывается, когда testзавершается, оставляя программу на Python, пытающуюся записать в канал, который никто не слушает.
Канал также используется, когда вы применяете подстановку процесса в bash(<(...)), поэтому здесь возникает та же проблема. В этих примерах данные поступают не через стандартный ввод, а из файла, указанного первым аргументом командной строки команды. Вы никогда не открываете этот файл.
Чтобы это исправить, убедитесь, что программа на языке C использует весь ввод из стандартного ввода или из имени пути, указанного первым аргументом команды.
Ваш текущий код не вызовет переполнения буфера, ошибки сегментации или любой другой ошибки в вашем коде C.
Я предполагаю, что вы хотите каким-то образом вызвать переполнение буфера в коде C. Вы бы сделали это, например, прочитав данные из кода Python в слишком маленький буфер.
Между прочим, код Python не обязательно должен быть Python, это может быть простая команда оболочки, которая производит много данных,например утилита yes(, возможно, переданная через head -n 1000или аналогичную, как вyes A | head -n 1000).