Pourquoi CURL return and error (23) Echec de l'écriture du corps?
Cela fonctionne bien comme un seul outil:
curl "someURL"
curl -o - "someURL"
mais cela ne fonctionne pas dans un pipeline:
curl "someURL" | tr -d '\n'
curl -o - "someURL" | tr -d '\n'
il retourne:
(23) Failed writing body
Quel est le problème dans la tuyauterie de la sortie curl? Comment mettre en tampon toute la sortie curl puis la gérer?
Cela se produit lorsqu'un programme canalisé (par exemple, grep) ferme le canal de lecture avant que le programme précédent ait fini d'écrire toute la page.
Dans curl "url" | grep -qs foo, dès que grep a ce qu'il veut, il ferme le flux de lecture de curl. cURL ne s'attend pas à cela et émet l'erreur "Échec du corps d'écriture".
Une solution de contournement consiste à diriger le flux vers un programme intermédiaire qui lit toujours la page entière avant de l'insérer dans le programme suivant.
Par exemple.
curl "url" | tac | tac | grep -qs foo
tac est un programme Unix simple qui lit l'intégralité de la page d'entrée et inverse l'ordre des lignes (nous l'exécutons donc deux fois). Comme il doit lire toute l'entrée pour trouver la dernière ligne, il ne restituera rien à grep tant que cURL n'est pas terminé. Grep fermera quand même le flux de lecture quand il aura ce qu'il cherche, mais cela n'affectera que tac, qui n'émettra pas d'erreur.
(Pour des informations plus complètes et pour les recherches futures).
ES: curl -s -N "URL" | grep -q Welcome
C'était donc un problème d'encodage. Iconv résout le problème
curl 'http://www.multitran.ru/c/m.exe?CL=1&s=hello&l1=1' | iconv -f windows-1251 | tr -dc '[:print:]' | ...
J'ai eu la même erreur mais pour une raison différente. Dans mon cas, j’avais une partition (tmpfs) avec seulement 1 Go d’espace et je téléchargeais un gros fichier qui finissait par rempli toute la mémoire sur cette partition et j’avais la même erreur que vous.
Vous pouvez le faire au lieu d'utiliser l'option -o:
curl [url] > [file]
Une autre possibilité, si vous utilisez l'option -o (fichier de sortie) - le répertoire de destination n'existe pas.
par exemple. si vous avez -o /tmp/download/abc.txt et/tmp/download n'existe pas.
Par conséquent, assurez-vous que tous les répertoires requis sont créés/existent à l’avance, utilisez l’option --create-dirs ainsi que -o si nécessaire.
J'ai rencontré ce message d'erreur en essayant d'installer le cache de vernis sur Ubuntu. La recherche Google m'a amené ici pour l'erreur
(23) Failed writing body, affichant ainsi une solution qui a fonctionné pour moi.
Le bogue est rencontré lors de l'exécution de la commande en tant que root curl -L https://packagecloud.io/varnishcache/varnish5/gpgkey | apt-key add -
la solution consiste à exécuter apt-key add en tant que root
curl -L https://packagecloud.io/varnishcache/varnish5/gpgkey | apt-key add -
Si vous essayez quelque chose de similaire, comme source <( curl -sS $url ) et obtenez l'erreur (23) Failed writing body, c'est parce que la recherche d'un processus de substitution ne fonctionne pas dans bash 3.2 (valeur par défaut pour macOS).
Au lieu de cela, vous pouvez utiliser cette solution de contournement.
source /dev/stdin <<<"$( curl -sS $url )"
Le serveur a manqué d'espace disque, dans mon cas.
Vérifiez-le avec df -k .
J'ai été alerté par le manque d'espace disque lorsque j'ai essayé deux fois de passer à tac, comme décrit dans l'une des réponses suivantes: https://stackoverflow.com/a/28879552/336694 . Il m'a montré le message d'erreur write error: No space left on device.
Pour moi, c'était une question de permission. Docker run est appelé avec un profil utilisateur mais root est l’utilisateur situé dans le conteneur. La solution consistait à faire en sorte que curl écrit sur/tmp, ce dernier ayant le droit d’écrire pour tous les utilisateurs, pas seulement root.
J'ai utilisé l'option -o.
-o/tmp/file_to_download