bash 为什么 cURL 返回错误“(23) 写入正文失败”？

Why does cURL return error "(23) Failed writing body"?

提问by static

It works ok as a single tool:

它可以作为单个工具正常工作：

curl "someURL"
curl -o - "someURL"

but it doesn't work in a pipeline:

但它在管道中不起作用：

curl "someURL" | tr -d '\n'
curl -o - "someURL" | tr -d '\n'

it returns:

它返回：

(23) Failed writing body

What is the problem with piping the cURL output? How to buffer the whole cURL output and then handle it?

管道 cURL 输出有什么问题？如何缓冲整个 cURL 输出然后处理它？

回答by Kaworu

This happens when a piped program (e.g. grep) closes the read pipe before the previous program is finished writing the whole page.

这发生在管道程序（例如 grep）在前一个程序完成写入整个页面之前关闭读取管道时。

In curl "url" | grep -qs foo, as soon as grep has what it wants it will close the read stream from curl. cURL doesn't expect this and emits the "Failed writing body" error.

在 中curl "url" | grep -qs foo，只要 grep 有它想要的东西，它就会关闭 curl 的读取流。cURL 没有预料到这一点，并发出“写入正文失败”错误。

A workaround is to pipe the stream through an intermediary program that always reads the whole page before feeding it to the next program.

一种解决方法是通过一个中间程序管道传输流，该程序在将其提供给下一个程序之前总是读取整个页面。

E.g.

例如

curl "url" | tac | tac | grep -qs foo

tacis a simple Unix program that reads the entire input page and reverses the line order (hence we run it twice). Because it has to read the whole input to find the last line, it will not output anything to grep until cURL is finished. Grep will still close the read stream when it has what it's looking for, but it will only affect tac, which doesn't emit an error.

tac是一个简单的 Unix 程序，它读取整个输入页面并反转行序（因此我们运行它两次）。因为它必须读取整个输入才能找到最后一行，所以在 cURL 完成之前它不会向 grep 输出任何内容。Grep 仍然会在它找到要查找的内容时关闭读取流，但它只会影响 tac，它不会发出错误。

回答by user5968839

For completeness and future searches:

为了完整性和未来的搜索：

It's a matter of how cURL manages the buffer, the buffer disables the output stream with the -N option.

这是 cURL 如何管理缓冲区的问题，缓冲区使用 -N 选项禁用输出流。

Example: curl -s -N "URL" | grep -q Welcome

例子： curl -s -N "URL" | grep -q Welcome

回答by MikeW

Another possibility, if using the -o(output file) option - the destination directory does not exist.

另一种可能性，如果使用-o（输出文件）选项 - 目标目录不存在。

eg. if you have -o /tmp/download/abc.txtand /tmp/download does not exist.

例如。如果您有-o /tmp/download/abc.txt并且 /tmp/download 不存在。

Hence, ensure any required directories are created/exist beforehand, use the --create-dirsoption as well as -oif necessary

因此，请确保事先创建/存在任何所需的目录，使用该--create-dirs选项以及 -o如有必要

回答by static

So it was a problem of encoding. Iconv solves the problem

所以这是一个编码问题。iconv 解决问题

curl 'http://www.multitran.ru/c/m.exe?CL=1&s=hello&l1=1' | iconv -f windows-1251 | tr -dc '[:print:]' | ...

回答by static

You can do this instead of using -ooption:

您可以这样做而不是使用-o选项：

curl [url] > [file]

curl [url] > [file]

回答by LLL

I had the same error but from different reason. In my case I had (tmpfs) partition with only 1GB space and I was downloading big file which finally filled all memoryon that partition and I got the same error as you.

我有同样的错误，但出于不同的原因。就我而言，我的 (tmpfs) 分区只有 1GB 空间，我正在下载大文件，最终填满了该分区上的所有内存，我遇到了与您相同的错误。

回答by HostedMetrics.com

The server ran out of disk space, in my case.

就我而言，服务器磁盘空间不足。

Check for it with df -k .

检查它 df -k .

I was alerted to the lack of disk space when I tried piping through tactwice, as described in one of the other answers: https://stackoverflow.com/a/28879552/336694. It showed me the error message write error: No space left on device.

tac如其他答案之一所述，当我尝试通过管道传输两次时，我收到磁盘空间不足的警报：https: //stackoverflow.com/a/28879552/336694。它向我展示了错误信息write error: No space left on device。

回答by wisbucky

If you are trying something similar like source <( curl -sS $url )and getting the (23) Failed writing bodyerror, it is because sourcing a process substitution doesn't work in bash 3.2(the default for macOS).

如果您正在尝试类似的操作source <( curl -sS $url )并收到(23) Failed writing body错误消息，那是因为在bash 3.2（macOS 的默认设置）中无法找到进程替换。

Instead, you can use this workaround.

相反，您可以使用此解决方法。

source /dev/stdin <<<"$( curl -sS $url )"

回答by lallolu

For me, it was permission issue. Docker run is called with a user profile but root is the user inside the container. The solution was to make curl write to /tmp since that has write permission for all users , not just root.

对我来说，这是许可问题。使用用户配置文件调用 Docker 运行，但 root 是容器内的用户。解决方案是让 curl 写入 /tmp，因为它对所有用户都有写权限，而不仅仅是 root。

I used the -o option.

我使用了 -o 选项。

-o /tmp/file_to_download

-o /tmp/file_to_download

回答by All ?? Vаи?тy

I encountered this error message while trying to install varnish cache on ubuntu. The google search landed me here for the error (23) Failed writing body, hence posting a solution that worked for me.

尝试在 ubuntu 上安装 varnish 缓存时遇到此错误消息。谷歌搜索让我在这里(23) Failed writing body遇到错误，因此发布了一个对我有用的解决方案。

The bug is encountered while running the command as root curl -L https://packagecloud.io/varnishcache/varnish5/gpgkey | apt-key add -

以 root 身份运行命令时遇到该错误 curl -L https://packagecloud.io/varnishcache/varnish5/gpgkey | apt-key add -

the solution is to run apt-key addas non root

解决方案是以apt-key add非root身份运行

curl -L https://packagecloud.io/varnishcache/varnish5/gpgkey | apt-key add -