If you're ever in the situation where you have access to a shell and need to download/install something, but don't have curl, wget, netcat or even telnet, find a handy bash script that lets you download a file from an HTTP source as a reply to this post.
It even fits in a single toot 😂
function __fakecurl() {
read proto server path <<<$(echo ${1//// })
DOC=/${path// //}
HOST=${server//:*}
PORT=${server//*:}
[[ x"${HOST}" == x"${PORT}" ]] && PORT=80
exec 3<>/dev/tcp/${HOST}/$PORT
echo -en "GET ${DOC} HTTP/1.1\r\nHost: ${HOST}\r\n\r\n" >&3
(while read line; do
[[ "$line" == $'\r' ]] && break
done && cat) <&3
exec 3>&-
}
@fribbledom I knew you would use that nefty feature of Bash that allows you to open descriptors and send all the things :P
@fribbledom Wouldn't this break if the server decided to send a chunked reply though? Probably setting HTTP to 1.0 would avoid that as it won't even support that
Indeed, you got a point!
@fribbledom
Not all bashes support /dev/tcp tho, I think at least Debian disables that feature.
@fribbledom I knew this before but it never fails to amaze me 👍
@fribbledom Unix: “Do one thing well.”
Bash: “No.”
@fribbledom hey look, it's a ~~~web microframework~~~ in the shell!!
@fribbledom
I'm confused about the syntax, what does exec 3<>... exactly do?
IO redirection (read/write) of /dev/tcp/${HOST}/$PORT
@fribbledom
I know 1 is stdout and 2 is stderr... so 3 is stdin?
There are three standard file descriptions: STDIN, STDOUT, and STDERR. They are assigned to 0, 1, and 2 respectively.
3 is the first unused descriptor, which we're setting up to read from and write to a TCP socket (the virtual device /dev/tcp/host/port).
@fribbledom the polite thing would be to add a Connection: close header
Server run by the main developers of the project 
It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!
Just echo/cat it to a file and then:
source fakecurl.sh
__fakecurl http://foo.bar/file.txt > file.txt