Using curl to get help on Linux commands, programming languages and more. The most comprehensive cheat sheet.

If you are looking for a Linux and programming cheat sheet, please check

It provides nicely colored help page, with plenty of examples in a CLI. Here are some sample runs I did.

Curl cheat sheet

daniel@hidmo:/tmp$ curl
# Download a single file

# Download a file and specify a new filename
curl -o

# Download multiple files
curl -O URLOfFirstFile -O URLOfSecondFile

# Download all sequentially numbered files (1-24)

# Download a file and follow redirects
curl -L

# Download a file and pass HTTP Authentication
curl -u username:password URL 

# Download a file with a Proxy
curl -x http://addressiwantto.access

# Download a file from FTP
curl -u username:password -O

# Get an FTP directory listing

# Resume a previously failed download
curl -C - -o

# Fetch only the HTTP headers from a response
curl -I

# Fetch your external IP and network info as JSON

# Limit the rate of a download
curl --limit-rate 1000B -O

# POST to a form
curl -F "name=user" -F "password=test"

curl -H "Content-Type: application/json" -X POST -d '{"user":"bob","pass":"123"}'

# POST data from the standard in / share data on
curl -F 'sprunge=<-'

Python lists cheat list

daniel@hidmo:/tmp$ curl
#  python - Why does += behave unexpectedly on lists?
#  The general answer is that += tries to call the __iadd__ special
#  method, and if that isn't available it tries to use __add__ instead.
#  So the issue is with the difference between these special methods.
#  The __iadd__ special method is for an in-place addition, that is it
#  mutates the object that it acts on. The __add__ special method returns
#  a new object and is also used for the standard + operator.
#  So when the += operator is used on an object which has an __iadd__
#  defined the object is modified in place. Otherwise it will instead try
#  to use the plain __add__ and return a new object.
#  That is why for mutable types like lists += changes the object's
#  value, whereas for immutable types like tuples, strings and integers a
#  new object is returned instead (a += b becomes equivalent to a = a +
#  b).
#  For types that support both __iadd__ and __add__ you therefore have to
#  be careful which one you use. a += b will call __iadd__ and mutate a,
#  whereas a = a + b will create a new object and assign it to a. They
#  are not the same operation!

>>> a1 = a2 = [1, 2]
>>> b1 = b2 = [1, 2]
>>> a1 += [3]          # Uses __iadd__, modifies a1 in-place
>>> b1 = b1 + [3]      # Uses __add__, creates new list, assigns it to b1
>>> a2
[1, 2, 3]              # a1 and a2 are still the same list
>>> b2
[1, 2]                 # whereas only b1 was changed

#  For immutable types (where you don't have an __iadd__) a += b and a =
#  a + b are equivalent. This is what lets you use += on immutable types,
#  which might seem a strange design decision until you consider that
#  otherwise you couldn't use += on immutable types like numbers!
#  [Scott Griffiths] [so/q/2347265] [cc by-sa 3.0]

Golang concurrency cheat sheet

daniel@hidmo:/tmp$ curl
 * go - When should I use concurrency in golang?
 * Not an expert in Go (yet) but I'd say:
 * Whenever it is easiest to do so.
 * The beauty of the concurrency model in Go is that it is not
 * fundamentally a multi-core architecture with checks and balances where
 * things usually break - it is a multi-threaded paradigm that not only
 * fits well into a multi-core architecture, it also fits well into a
 * distributed system architecture.
 * You do not have to make special arrangements for multiple goroutines
 * to work together harmoniously - they just do!
 * Here's an example of a naturally concurrent algorithm - I want to
 * merge multiple channels into one. Once all of the input channels are
 * exhausted I want to close the output channel.
 * It is just simpler to use concurrency - in fact it doesn't even look
 * like concurrency - it looks almost procedural.

  Multiplex a number of channels into one.
func Mux(channels []chan big.Int) chan big.Int {
    // Count down as each channel closes. When hits zero - close ch.
    var wg sync.WaitGroup
    // The channel to output to.
    ch := make(chan big.Int, len(channels))

    // Make one go per channel.
    for _, c := range channels {
        go func(c <-chan big.Int) {
            // Pump it.
            for x := range c {
                ch <- x
            // It closed.
    // Close the channel when the pumping is finished.
    go func() {
        // Wait for everyone to be done.
        // Close.
    return ch

 * The only concession I have to make to concurrency here is to use a
 * sync.WaitGroup as a counter for concurrent counting.
 * Note that this is not purely my own work - I had a great deal of help
 * with this here (
 * [OldCurmudgeon] [so/q/19747950] [cc by-sa 3.0]

Please check for more information on installation and using its comprehensive features.