Он работает нормально как один инструмент:
curl "someURL"
curl -o - "someURL"
но он не работает в конвейере:
curl "someURL" | tr -d '\n'
curl -o - "someURL" | tr -d '\n'
он возвращает:
(23) Failed writing body
В чем проблема в конвейерной работе с выкруткой? Как буферировать весь вывод curl, а затем обрабатывать его?
Это происходит, когда программа с каналами (например, grep) закрывает канал чтения до того, как предыдущая программа завершит запись всей страницы.
В curl "url" | grep -qs foo, как только grep получит то, что он хочет, он закроет поток чтения из curl. cURL не ожидает этого и испускает ошибку "Failed writing body".
Обходной путь заключается в том, чтобы передать поток через посредническую программу, которая всегда читает всю страницу, прежде чем подавать ее в следующую программу.
например.
curl "url" | tac | tac | grep -qs foo
tac - простая программа Unix, которая читает всю страницу ввода и меняет порядок строк (поэтому мы запускаем ее дважды). Поскольку он должен прочитать весь ввод, чтобы найти последнюю строку, он ничего не выводит grep, пока cURL не будет закончен. Grep по-прежнему будет закрывать поток чтения, если он имеет то, что он ищет, но он будет влиять только на tac, который не испускает ошибку.
(Для полноты и будущих поисков) Вопрос в том, как CURL управляет буфером, буфер отключает выходной поток с опцией -N.
Пример:
curl -s -N "URL" | grep -q Welcome
Другая возможность, если используется опция -o (выходной файл) - целевой каталог не существует.
например. если у вас есть -o /tmp/download/abc.txt и /tmp/download не существует.
Следовательно, убедитесь, что все необходимые каталоги созданы/существуют заранее, используйте опцию --create-dirs, а также - o при необходимости.
Так что это была проблема кодирования. Iconv решает проблему
curl 'http://www.multitran.ru/c/m.exe?CL=1&s=hello&l1=1' | iconv -f windows-1251 | tr -dc '[:print:]' | ...
Вы можете сделать это вместо использования опции -o:
curl [url] > [file]
У меня была такая же ошибка, но по разным причинам. В моем случае у меня был раздел (tmpfs) с размером всего 1 ГБ, и я загружал большой файл, который, наконец, заполнил всю память на этом разделе, и я получил ту же ошибку, что и вы.
В моем случае на сервере не хватило места на диске.
Проверьте это с помощью df -k .
Я был предупрежден о нехватке дискового пространства, когда я дважды попытался передать по каналу tac, как описано в одном из других ответов: fooobar.com/questions/102897/.... Он показал мне сообщение об ошибке write error: No space left on device.
Я столкнулся с этим сообщением об ошибке при попытке установить кэш-лак в Ubuntu. Поиск в Google привел меня сюда из-за ошибки
(23) Failed writing body, поэтому я опубликовал решение, которое помогло мне.
Обнаружена ошибка при запуске команды от имени пользователя root curl -L https://packagecloud.io/varnishcache/varnish5/gpgkey | apt-key add -
решение состоит в том, чтобы запустить apt-key add от имени пользователя root
curl -L https://packagecloud.io/varnishcache/varnish5/gpgkey | apt-key add -
Для меня это был вопрос разрешения. Запуск Docker вызывается с профилем пользователя, но root - это пользователь внутри контейнера. Решением было сделать запись curl в /tmp, поскольку она имеет разрешение на запись для всех пользователей, а не только для пользователя root.
Я использовал опцию -o.
-o/tmp/file_to_download
Если вы пытаетесь сделать что-то подобное, например, source <( curl -sS $url ), и получаете ошибку (23) Failed writing body, то это потому, что замена процесса не работает в bash 3.2 (по умолчанию для macOS).
Вместо этого вы можете использовать этот обходной путь.
source /dev/stdin <<<"$( curl -sS $url )"