Co robi „echo ipv4 >> ~ / .curlrc”?

Dzisiaj miałem problem z instalacją kompozytora za pomocą poniższego polecenia:

curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer

Dał mi ten błąd:

curl: (7) Failed to connect to getcomposer.org port 443: Network is unreachable

Poszukałem google i znalazłem to polecenie :

echo ipv4 >> ~/.curlrc

Uruchomiłem to i naprawiłem problem, a kompozytor został zainstalowany poprawnie.

Ale nie wiem, co robi powyższe polecenie, czy ktoś mógłby to wyjaśnić?

command-line ip curl Prashant Kumar
źródło

@Melebius Dodano link :)

Prashant Kumar

Odpowiedzi:

W tym celu dodaje się „ipv4” do pliku „curlrc”. Przykład zaczynający się od pustego pliku:

$ touch 1
$ more 1
$ echo ipv4 >> 1
$ more 1
ipv4

Zasadniczo zmusza curl do korzystania z ipv4.

Instrukcja ma do powiedzenia na ten temat:

IPv6

curl połączy się z serwerem z IPv6, gdy wyszukiwanie hosta zwróci adres IPv6 i wróci do IPv4, jeśli połączenie się nie powiedzie. Te --ipv4i --ipv6opcje można określić adres używać gdy oba są dostępne. Adresy IPv6 można również określić bezpośrednio w adresach URL przy użyciu składni

Rinzwind
źródło

Uruchomiłem tylko to polecenie, zadziałało, więc myślę, że jest poprawne. Tylko jedno pytanie, dlaczego mój kompozytor nie działał na pierwszym miejscu i dlaczego zadziałało po tym poleceniu. Co myślę oznacza, że wcześniej curl próbował użyć sieci ipv6, która tak naprawdę nie jest skonfigurowana. Czy to czy coś innego?

Prashant Kumar

Zakładam, że tak było: połączenie odmówiło, ponieważ otrzymałeś je z oczekiwanego IPv6. Ta edycja pliku wymusza ipv4.

Rinzwind

ale jak powiedziałeś,

curl will connect to a server with IPv6 when a host lookup returns an IPv6 address and fall back to IPv4 if the connection fails

dlaczego mój system po prostu popełnił błąd, zamiast tego próbował uzyskać dostęp do ipv4 sam, jeśli nie znalazł ipv6.

Prashant Kumar

.curlrcużywa nazw opcji bez wiodącego -lub --.

chepner

Typową konwencją w systemie UNIX jest to, że programy (zwykle) odczytują konfigurację uruchamiania z różnych predefiniowanych plików. To tylko tradycja, a nie nic zdefiniowanego przez POSIX lub inny standard. Typowy program UNIX np. foobarCzytałby w następującej kolejności:

~/.foobarrc  ## User specific configuration parameters
/etc/foobarrc  ## Global parameters, depending on taste
               ## `/etc/foobar/*(.conf)' might be chosen too

Może wystąpić awaria, /usr/share/ale nie jest to zbyt częste.

A więc curltutaj, postępując zgodnie z konwencją i czytając jej początkową konfigurację ~/.curlrc. W ten echo ipv4 >>~/.curlrcsposób dodałeś ciąg ipv4do pliku ~/.curlrc.

Ciąg ipv4ma specjalne znaczenie dla curl- curlużyje wtedy IPv4 do rozpoznania hosta. Jest to analogiczne do używania argumentu -4/ ipv4as curlz wiersza poleceń, ale zapisanie go ~/.curlrcpowoduje, że jest to stałe.

Jak już ipv4tam ustawiłeś, a teraz wszystko działa dla ciebie, prawdopodobnie masz skonfigurowany IPv6 i curlwcześniej używałeś IPv6 do (udanego) rozpoznawania hosta, więc nie powrócisz do IPv4. Połączenie z witryną nie powiodło się, ponieważ nie wszystkie witryny mają skonfigurowane serwery WWW do nasłuchiwania na adresach IPv6, więc socket()połączenie zakończy się niepowodzeniem, jak widzimy w tym przypadku.

heemayl
źródło

W praktyce jednak /etc/foobar.confnajpierw czytano ~/.foobarrcby, aby ten drugi mógł zastąpić ten pierwszy. Tak więc, jeśli /etc/foobar.confzawiera wiersz, który mówi frobnitz=0i ~/.foobarrcma frobnitz=1, ta ostatnia wartość ma pierwszeństwo

Monty Harder

@MontyHarder Dokładnie o to mi chodziło według porządku pierwszeństwa ...

heemayl

Tak, kolejność pierwszeństwa, a nie kolejność czytania.

Monty Harder