Archive for November 17th, 2019

Linux – Cheat sheet

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.

curl – use variables to show response times and other parameters

curl is a tool to interact with a server for transferring data. Although it supports various protocols, it is most commonly used with HTTP/S. It is sort of a browser for CLI folks and a go to tool when writing scripts to interact with servers.

In addition to transferring data, how do we show request and response parameters with curl. The answer is using variables, the complete list of variables can be found here.

Example – use “time_total” to show the total time, in seconds, that the full operation lasted.

$ curl  -w %{time_total}

It is best to add the variables in a file and use curl to reference the file for better formatting. Here I have added several http request and response variables I am interested in, such as num_connects, size_download, size_header, time_namelookup, time_pretransfer etc.

daniel@hidmo:/tmp$ cat ccurl.txt 
      url_effective:  %{url_effective}\n
       content_type:  %{content_type}\n
          http_code:  %{http_code}\n
       http_version:  %{http_version}\n
       num_connects:  %{num_connects}\n
      num_redirects:  %{num_redirects}\n
          remote_ip:  %{remote_ip}\n
      size_download:  %{size_download}\n
        size_header:  %{size_header}\n
    time_namelookup:  %{time_namelookup}\n
       time_connect:  %{time_connect}\n
    time_appconnect:  %{time_appconnect}\n
   time_pretransfer:  %{time_pretransfer}\n
      time_redirect:  %{time_redirect}\n
 time_starttransfer:  %{time_starttransfer}\n
         time_total:  %{time_total}\n

daniel@hidmo:/tmp$ curl -H 'Cache-Control: no-cache' -L -w "@ccurl.txt" -o /dev/null -s
       content_type:  text/html; charset=UTF-8
          http_code:  200
       http_version:  1.1
       num_connects:  2
      num_redirects:  1
      size_download:  71273
        size_header:  537
    time_namelookup:  0.008585
       time_connect:  0.082511
    time_appconnect:  0.264110
   time_pretransfer:  0.264293
      time_redirect:  1.287257
 time_starttransfer:  3.077526
         time_total:  3.177939

As far as time related parameters, listed below are the ones you will most likely use –

  • time_appconnect The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed. (Added in 7.19.0)
  • time_connect The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.
  • time_namelookup The time, in seconds, it took from the start until the name resolving was completed.
  • time_pretransfer The time, in seconds, it took from the start until the file transfer was just about to begin. This includes all pre-transfer commands and negotiations that are specific to the particular protocol(s) involved.
  • time_redirect The time, in seconds, it took for all redirection steps including name lookup, connect, pretransfer and transfer before the final transaction was started. time_redirect shows the complete execution time for multiple redirections. (Added in 7.12.3)
  • time_starttransfer The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.
  • time_total The total time, in seconds, that the full operation lasted.

References –