What does "echo ipv4 >> ~/.curlrc" do?

I was facing some issue today when trying to install composer with the below command:

curl -sS | sudo php -- --install-dir=/usr/local/bin --filename=composer

It was giving me this error:

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

I googled and found this command:

echo ipv4 >> ~/.curlrc

I ran this and it fixed the problem and composer installed just fine.

But I don't know what the above command does, could anyone explain it?

2 Answers

What is does is add "ipv4" to the file "curlrc". Example starting with an empty file:

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

Basically it forces curl to use ipv4.

The manual has this to say about it:

IPv6

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. The --ipv4 and --ipv6 options can specify which address to use when both are available. IPv6 addresses can also be specified directly in URLs using the syntax

A typical convention in UNIX is that programs (usually) read their startup configuration from various predefined files. This is merely a tradition, not anything defined by POSIX or any other standard. A typical UNIX program e.g. foobar would read, in the following order of precedence:

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

There might be a fallback in /usr/share/ but that is not very common.

So, curl here following the convention and reading it's initial configuration from ~/.curlrc. And by doing echo ipv4 >>~/.curlrc, you have appended the string ipv4 to the file ~/.curlrc.

The string ipv4 has a special meaning to curl -- curl will use IPv4 for host resolution then. This is analogous to using -4/ipv4 as curl's argument from command line, but saving to ~/.curlrc makes this permanent.

As you have set ipv4 in there and now everything works for you, presumably you have IPv6 configured, and curl were previously using IPv6 for (successful) host resolution, so no fallback to IPv4. The connection to the site was failing because not all sites have their webservers configured to listen on IPv6 addresses, so the socket() call would fail as we can see in this case.