terminal Generatore di Comandi curl star

Breve storia di curl

curl fu creato nel 1998 dallo sviluppatore svedese Daniel Stenberg, che ne scrisse la prima versione per recuperare automaticamente i tassi di cambio delle valute per un bot IRC su un canale di chat svedese — un piccolo bisogno personale, non un grande piano per costruire un'infrastruttura. Le persone continuarono a chiedere più protocolli e più opzioni, e quella piccola utility si trasformò in uno strumento a riga di comando general-purpose per trasferire dati via HTTP, HTTPS, FTP e, col tempo, decine di altri protocolli. Stenberg è rimasto il manutentore principale di curl per praticamente tutta la sua esistenza; oggi curl è preinstallato di default su macOS, su praticamente ogni distribuzione Linux e — dal 2018 — su Windows 10 e versioni successive, e si stima che giri su miliardi di dispositivi in tutto il mondo, dai router alle automobili, dalle console di gioco a quasi ogni pipeline di integrazione continua che comunica con un'API. Ciò che è iniziato come la soluzione a un problema personale molto circoscritto è oggi, probabilmente, il client HTTP a riga di comando più diffuso in assoluto, e uno dei software open source di cui internet dipende più silenziosamente.

Come interpretare i flag generati da questo strumento

Per impostazione predefinita, curl non segue i redirect HTTP. Se un server risponde con uno stato 301 o 302 e un header Location che punta altrove, curl senza opzioni aggiuntive stampa quella risposta di redirect — o un corpo vuoto — e si ferma; non insegue automaticamente il nuovo URL come fa silenziosamente un browser web. Questo confonde un numero enorme di utenti alle prime armi con curl: un URL che funziona perfettamente in un browser restituisce una risposta confusa, vuota o sbagliata da curl, apparentemente senza motivo, semplicemente perché il browser ha seguito un redirect che curl non ha seguito. La soluzione è il flag -L (--location), che dice a curl di seguire la catena di redirect fino alla destinazione finale. È un'esigenza così comune che molti sviluppatori usano -L di default ogni volta che non stanno deliberatamente testando il comportamento dei redirect in sé.

Non appena un comando include header o contenuti del corpo con spazi, virgolette o caratteri speciali della shell ($, &, ;, apici inversi), il modo in cui li racchiudi tra virgolette smette di essere una questione estetica — diventa la differenza tra una richiesta che funziona e una che la shell corrompe prima ancora che curl la veda. Un header come Authorization: Bearer abc 123 digitato senza virgolette viene diviso dalla shell in corrispondenza dello spazio, quindi curl riceve Authorization: e Bearer come due argomenti separati e rotti invece di uno solo. Racchiudere l'intero valore tra apici singoli dice alla shell di trattare tutto ciò che è all'interno alla lettera, spazi inclusi — ma gli apici singoli non possono contenere al loro interno un apice singolo letterale, dato che è proprio quel carattere a chiudere la citazione. La soluzione standard per questo caso è chiudere la citazione, inserire un apice singolo preceduto da backslash e riaprire la citazione: '\''. Questo strumento applica automaticamente questa sequenza di escape a ogni valore che inserisce, così header, contenuto del corpo e credenziali di autenticazione che contengono spazi, virgolette o altri caratteri speciali producono sempre un comando che funziona correttamente — senza che tu debba memorizzare le regole di escape.