Почему Подверсия дает поврежденную ошибку канала при передаче по каналу в голову?
Существует несколько различных init систем для Linux. Основными является SysVinit (традиционный), Выскочка (замена Ubuntu), и SystemD (продвинутый Fedora и Gnome). Каталоги /etc/init.d и /etc/rc?.d используются SysVinit. Книга может упоминать их относительно Ubuntu, потому что информация немного датирована (Ubuntu раньше использовала SysVinit как все остальные), или потому что те каталоги все еще существуют для совместимости.
/etc/init.d содержит набор сценариев, каждый содержащий инструкции запустить и остановить сервис. Некоторые из этих сервисов должны быть запущены во время начальной загрузки; другие должны быть запущены в многопользовательском режиме, но не в однопользовательском режиме техобслуживания; и возможно определить различные режимы с различными наборами желаемых сервисов. SysVinit управляет этим через runlevels. Каталог /etc/rc$N.d содержите сценарии для выполнения при вводе runlevel N (/etc/rc$N.d/S*) и сценарии для выполнения при отъезде runlevel N (/etc/rc$N.d/K*). Поскольку много runlevels есть общие сценарии, а не хранят копию сценариев для каждого runlevel, сценарии все хранятся в единственном месте /etc/init.d, и runlevel-определенные каталоги /etc/rc?.d содержите символьные ссылки. Кроме того, названия символьных ссылок указывают, должен ли сервис быть запущен (S*) или остановился (уничтоженный, K*) в этом runlevel и числовой префикс используются для управления порядком, в котором выполняются сценарии.
Сценарий, ответственный за то, что пересек /etc/rc$N.d /etc/init.d/rc (на предварительной выскочке Ubuntu и на Debian; местоположения могут варьироваться на других дистрибутивах Linux).
Когда Вы пишете в канал, другой конец которого был закрыт, Вы обычно получаете сигнал SIGPIPE и умираете. Однако, если Вы принимаете решение проигнорировать тот сигнал, как svn делает, затем вместо этого write возвраты с -1 и errno набор к EPIPE чей английский перевод "Повреждается канал". И svn принимает решение отобразить то сообщение об ошибке, когда ему не удается записать что-то в его стандартный вывод.
head завершается после того, как это записало 10 строк из своего входа и в результате закрывает канал. svn не сможет записать больше в тот канал. Большинство приложений затем умирает тихо как поведение по умолчанию, когда они не игнорируют SIGPIPE. svn по некоторым причинам (возможно, потому что это должно сделать дополнительные вещи прежде, чем умереть) принимает решение проигнорировать SIGPIPE и решить, что это не может больше писать в канал путем проверки ошибочного состояния write к каналу.
Вы получаете ту же ошибку с:
bash -c 'trap "" PIPE; while echo foo; do :;done' | head
См.:
strace -e write seq 10000 | head
(на Linux) для наблюдения то, чем состоит в том поведение по умолчанию, когда Вы не игнорируете SIGPIPE.
Это - давняя проблема Подверсии (сначала повышенный в 2007, и не зафиксированное до 2011). Причины для svn разработчиков, не устраняющих его так долго, не совсем ясны, но можно считать все окровавленные детали, включая которые это было зафиксировано в 1.7.0 в связанном отчете об ошибках. Таким образом, если это поведение является действительно проблемой для Вас, затем проверьте свою svn версию клиента (svn --version), и рассмотрите обновление...