Syntax highlighting in pagers (eg. like less) using GNU source-highlight
Mar 21st, 2021 by miki

EDIT 2021-08-31: add section about possible unexpected change of behaviour when using the simple (global) setup (fx. git)

There is this nifty OS project, GNU, which has this nifty piece of software for syntax highlighting, source-highlight (aka. src-highlite), together with which is distributed this nifty shell script,, meant for piping arbitrary text through the highlighter selecting and applying a sensible highlight language definition, before being paged in some nifty pager which is able to interpret ANSI escape codes (ISO/IEC 6429 or ECMA-48, previously ANSI X3.64/FIPS PUB 86) like fx. the nifty and ubiquitous less.

Sadly, even after having installed less and source-highlight on modern Ubuntu and Debian systems they are not inter-operating by default. You’d have to feel the itch of syntax highlighting, discover source-highlight and dig its documentation to find out about said script.

TL;DR – quick and simple setup

Below is a quick two-line shell HOW-TO which sets up environment variables for the current user to enable auto-detection of language and subsequent syntax highlighting pr. default in less using GNU source-highlight (here done on Ubuntu 20.04 LTS, should behave similarly on Debian and derived distributions);

$ sudo apt install source-highlight
$ echo -e "\nexport LESSOPEN=\"| /usr/share/source-highlight/ %s\"\nexport LESS=' -R '" >> ~/.bash_aliases


This setup will make fx. some C source code display as below in less.

environment set up for less to enable ANSI color codes and pass any text through source-highlighter for potential ANSI escape code addition

less showing highlighted C code, auto-detected and highlighted by GNU source-highlighter

Complicating TL;DR

One caveat of this global setup being active for any invocation of less, is that most programs will behave accordingly and some maybe different from expectations.

Notably, using the git command line client with the above setup will make git refrain from setting a default LESS=FRX environment (see core.pager of man git config) when invoking less. This turns off the less features “quit-if-one-screen” (F) and “no-init” (X) (see OPTIONS of man less) which usually makes less invisible in git contexts unless paging is actually needed. This could cause confusion for some, making git seemingly take over the terminal on even 1 line outputs (see this bug report on GNU src-hilite and my comment detailing the above).

One solution to this would of course be to add “FX” to the environment, another is making a little more elaborate, more conservative and less transparent setup, as below.

For the conservative

If you’d still like to have a “plain less” not messing with and amending you text unless you ask it to, you could make an alias to use specifically when you want syntax highlighting. Put these somewhere interpreted by you shell (for bash fx. ~/.bash_aliases);

# syntax highlight in less
alias lesssh="LESSOPEN='|/usr/share/source-highlight/ %s' LESS=' -R ' less"
function lessurl() { wget -O- -q $1 |source-highlight -f esc -s html |less -R; }

Line two is a bonus shell function pulling some HTML from a webserver using wget, adding syntax highlighting and showing it in less.

Digging deeper

For the brave, take a tour of the “info source-highlight” (or “man source-highlight”) manuals (also here) to become familiar with the tool. You can use it anywhere you’d like some colour on arbitrary text and where color are supported in various ways and encodings, for example HTML and latex;

source-highlight adding color encoding to C code using HTML and latex encoding

If you are a programmer wanting to add highlighting features to you own application, the command line utilities are building on a highlighting library which you can utilise (API documentation here).

[Danish] Micro:bit driftstemperatur
Dec 2nd, 2020 by miki

Endnu en, af de heldigvis mere sjældne, forvildelser ind på Facebook, som førte til en tur omkring Micro:bit-platformen, og nogle detaljer omkring dens hardware og manglende specifikationer.


Et lidt underligt spørgsmål måske, men er der nogen der har gjort sig erfaringer med Micro:bit i frostvejr – Er den stabil, og kan den starte op i f.eks. -20 grader ?
Jeg har googlet – men søgeresultatet på de relevante søgning er temmelig forurenet af at der jo er en indbygget temperatursensor…


Ja, det ser da lidt underligt ud. Der er ikke opgivet nogen driftstemperatur (“oprarating temperature”) eller for så vidt opbevaringstemperatur (“storage temperature”) i specifikationerne for hverken V1.5 ( eller V2 (

En søgning i dokumentationens git-arkiv bekræfter at der kun nævnes noget om temperaturer når den indbyggede sensor i nRF-SoC’en omtales ( Ligeledes bruges ordet “operating” kun om spænding, strøm og system (=OS) (

Så den oplysning er Micro:bit Foundation åbenbart ikke særligt vilde med at dele, hvilket tyder på at det ikke har været en prioritet under design og produktion (hvilket er forståeligt nok for et ikke-industrielt stykke undervisningsmateriale). Så du skal nok under alle omstændigheder ikke forvente en konsistent oplevelse.

Hvis man skulle give et kvalificeret bud, kunne man kigger på hovedkomponenternes specificerede driftstemperaturer, hvilket i hvert fald siger noget om de øvre og nedre grænser, men komponenternes komplekse interaktioner med hinanden (mekanisk, termisk, elektrisk) i det færdige produkt har selvfølgelig betydning for de endelige grænser.



Det giver da et fingerpeg, god fornøjelse med fryseren ;).

DK01 Campus: Bulk Infrastructure Building Site
Nov 4th, 2020 by miki

I took the chance on a summer day last year, 2019-06-20, to take a peek at the construction site of the Norwegian Bulk Infrastructure data center DK01 Campus being built in Kjersing, Esbjerg, Denmark. The pictures were stowed away until now but I think they deserve to be set free, so here goes.

Fiber Network

The data center is a part of Bulk Infrastructure’s involvement in the Havfrue/AEC-2 subsea cable system (link to a previous blog post with details), built in cooperation with Google and Facebook, which is going to land on the Western shore of Jutland in the near future (ready for service expected in 2020-Q3). Bulk Infrastructure is going to build and operate an extension of the main cable trunk (with reduced capacity) to Norway and its datacenters present there.

It seems the DK01 Campus data center is going to act as an exchange point between other fiber networks Bulk is involved in and also landing in Esbjerg;

  • Havfrue (mermaid) – New Jersey/Dublin/Kristianssand


  • Havhingsten (sea horse)  – Newcastle/Dublin


  • Havsil (sea herring) – Kristianssand/Hanstholm



The location in Esbjerg is indicated by the orange area outline on the map below, courtesy of OpenStreetMap.

Construction Site Photos

Arriving to the area from the highway driving along the Kjersing Ringvej the site is partly visible at your left hand.



Taking the 3rd exit in the roundabout onto Guldborgsundvej and turning the first left corner the site is just in front of you on the right.


Getting close the inner construction work is visible through the still open facade.


Stepping out and taking a snapshot closer to the fence.


Walking around the end of the building. Small compartments are visible.


At the other side there’s some foundation extending from the tall white wall barely visible. It is probably going to have lighter walls erected. Could be administration offices, where the high ceiling room with walls already standing is the main data center hall.


A lot of temporary arrangements on site for the construction period and site protection.


For the guests, like me, there is even a nice information board with outline map showing some details. As anticipated, offices on left side of the data center hall (right side of the building in the yellow marking, map is facing North, most pictures taken South-West). And also smaller rooms in the hall itself in the Northerne end of the building that we saw above. This is probably to be able to segment co-located equipment for restricting access.

VCTA Detour Wednesday/Omvejsonsdag – new paths for your wheels
Sep 24th, 2020 by miki

The Danish Cyclists’ Federation (Cyklistforbundet) throws a yearly month long event called BIKE TO WORK (“Vi Cykler Til Arbejde” aka. VCTA) nudging employees of Danish workplaces to use their bike for commuting. Teams are formed by the employees and team statistics are available both internally and between workplaces for the teams to compete in the number of kilometres travelled and number of active days. See f.x. the statistics for the two teams of my employer Vestergaard. Of course my outdoor, social, competitive, and sometimes a bit extreme, mindset can’t miss such a chance to commit to an all-in full month bike relay race with myself and some distant (300 km to HQ) colleagues.

As a part of the VCTA month of cycling one day is designated to taking an unknown route to work, dubbed “Detour Wednesday” (“Omvejsonsdag“). This is to inspire the individual to find new routes and get some fresh input on the surroundings. This year it was Wednesday September 23th, and the event even includes a draw of an electric powered bike amongst participants documenting their detour appropriately.

For your enjoyment, below are some visual impressions from my nice detour in the Tjæreborg/Bramming area (of Western Jutland, Denmark). Even though I have been to all these places before by various different means (running, cycling, car, motorcycle), you do sense a place a lot different on the bike than by other means.

All The Maps

Being the dev/hacker/tinkerer/geo person that I am, although not extremely well-versed in HTML/javascript, I have also made a quick throw together of a visualisation on top of Leaflet and OpenStreetMap of the tracks I’ve recorded during VCTA.

Find it at, and source code at

My VCTA tracks pr. 2020-09-24 visualised by some hackish javascript on (code).


The start of the Wadden Sea dykes at Roborg near Tjæreborg. National cycle route 1 (N1 – Vestkystruten) runs along here. Location: 55.45083;8.56325

In front of Sneum Sluse, where Sneum Å joins the sea. Location: 55.43321;8.60780

Along the dyke between Sneum Sluse and Darum. Approximate location: 55.42917;8.62244


Crossing Sneum Å again, this time in-land approximately 12 km upstream from Sneum Sluse. Location: 55.49637;8.69648

Following national cycle route 6 (N6 – Esbjerg-København) and regional cycle route 10 heading back towards Ålbæk, Opsneum and Tjæreborg. Location: 55.49874;8.69664


The tracks as recorded by Endomondo;

The tracks as recorded by OpenTracks (Application: F-Droid, Github, Google Play, OSM Dashboard: F-Droid, Github, Google Play).

Outgoing track as recorded by OpenTracks.

Homegoing track as recorded by OpenTracks. database id becoming a meteorological location reference
Aug 20th, 2020 by miki

Looking at weather forecasts in my native Denmark I have always noticed a location reference used by DMI, Danmarks Meteorologiske Institut (en:Danish Meteorological Institute). Somehow I managed to not look into the details of that before now.

But this morning while scouting for rain showers and trying out the forecast on the new website of Yr (the long time open data weather service from Norwegian Broadcasting Corporation (NRK) and the Norwegian Meteorological institute (MET)), as kindly suggested by the YR main site which uses the old site by default, I saw the same reference included in the URL.

A closer look at different service’s forecast URLs for my usual whereabouts in Tjæreborg, Denmark, Europe, Earth reveals (se summary below) that they all share this reference and that it stems from the (wikipedia article) database’s integer reference to the location:

This particular piece of data is described as a field in the “geoname” table of the main database, and referred to as “geonameid” in the documentation:

geonameid         : integer id of record in geonames database

The contents of the database is licensed under the Creative Commons Attribution 4.0 International (aka. “CC BY 4.0”, SPDX ID:”CC-BY-4.0″) and available both for your own download and perusal (documentation here) or using web services on

Note, however, that accumulates a wealth of data sources that according to the OpenStreetMap project might contain copyrighted data. Together with the attribution requirements of its CC BY license this causes OpenStreetMap to not accept data from into the project’s, ODbL licensed, database.

Fun fact: in Norwegian “yr” actually means drizzle (da:støvregn)
Practical hint: OpenSearch entry for (to add in current browser: go here->find “Plugins”->click “opensearch plugin”)

The Weather Services

2611610 on

“Get”ting from web service

$ wget -q -O- ""
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
    <fclName>city, village,...</fclName>
    <fcodeName>populated place</fcodeName>
    <adminCode1 ISO3166-2="83">21</adminCode1>
    <adminName1>South Denmark</adminName1>
    <adminName2>Esbjerg Kommune</adminName2>
    <alternateName lang="post">6731</alternateName>
    <alternateName lang="unlc">DKTJA</alternateName>
    <alternateName lang="link"></alternateName>
    <timezone dstOffset="2.0" gmtOffset="1.0">Europe/Copenhagen</timezone>

Extracting from “Gazetteer” exports

$ wget -q
$ unzip 
  inflating: readme.txt              
  inflating: DK.txt                  
$ grep ^2611610 DK.txt
2611610	Tjæreborg	Tjaereborg	Tjaereborg,Tjæreborg	55.46457	8.57968	P	PPL	DK\
		21	561			2146		12	Europe/Copenhagen	2017-10-18


Amending an open OSM changeset on command line (by hand)
Jul 25th, 2020 by miki

WARNING: as OSM user “mmd” wisely points out (in comment to OSM diary for this post) the sort of thing described here is dangerous to do by hand, and should not be done on the main production instances (there are testing instances for playing around with the API, a little documentation here).
He also points out that the feature packed JOSM editor actually supports continuing a changeset regardless of where it has been initiated. So if you just need to continue working on a changeset (but remember the 1 hour idle timeout) be sure to check out the JSOM upload documentation. Thanks mmd, for being the sane voice ;).

During an editing session the Android OpenStreetMap editor Vespucci crashed on me, which made the mapping UI unusable (objects greyed out and unable to select or edit, had to purge all data to recover functionality). Luckly, I could still navigate the menus, upload changes and opt to not close the changeset. Now, I had long wondered whether the OSM API allowed to continue amending changes to an open changeset from some other editor, so the quest began.

I had the intention of adding a tag representing the name of a building in Esbjerg known as “ISC Huset” (ISC is an engineering consultancy, see wikipedia, and more about the construction), which houses a number of healtcare clinics. The building’s address is Borgergade 70, 6700 Esbjerg (current address node).

This blog post willl attempt to actually add the tag by hand on the command line.

References to OSM objects used:

Option summary for GNU wget used to do HTTP requests below:

  • -nv (or –no-verbose): only report errors and basic information
  • -O- (or –output-document=-): write output to standard out (stdout)
  • –user=<user name>: authenticate as <user name> using HTTP Basic authentication
  • –ask-password: ask on command line for HTTP Basic authentication password
  • –post-data=”<data>”: initiate a HTTP POST request with <data> as payload
  • –server-response (or -S): show full HTTP headers of server response

NOTE: I’ve broken some long output lines replicated below to make it fit the blog, but inserted an escape character (\) before the inserted newline to help copy’n’pasting.

Retrieve changeset metadata

Lets start by looking at the changeset’s metadata.

This can be done by issuing an unauthenticated GET request to the “/api/0.6/changeset/<changeset id>” endpoint.

Note that the ‘changeset’ element has the attribute ‘open=”true”‘ required to be able to modify the changeset. The editor used to create the changeset needs to have done this without explicitly closing it (Vespucci & JOSM closes by default but can be configured not to, iD always closes).

$ wget -nv -O-
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.8.3 (802" copyright="OpenStreetMap and contributors"\
 attribution="" license="">
 <changeset id="88490797" created_at="2020-07-25T09:51:30Z" open="true" user="mikini" uid="2051"\
 min_lat="55.4654072" min_lon="8.4378053" max_lat="55.5258532" max_lon="8.4639026" comments_count="0" changes_count="68">
  <tag k="source" v="survey;research"/>
  <tag k="locale" v="da-DK"/>
  <tag k="created_by" v="Vespucci"/>
  <tag k="comment" v="Details at Klevestien &amp; Borgergade in Esbjerg and Tarp."/>
2020-07-25 14:26:52 URL: [709] -> "-" [1]

Pinging the changeset with an empty osmChange structure

To test that the changeset is open, and that we can authenticate correctly, lets try amending it with an empty osmChange structure.

This can be done by issuing an authenticated POST request to the “/api/0.6/changeset/<changeset id>/upload” endpoint.

This also seem to reset the 60 minute timer used for auto-closing the changeset (see mention of “idle timeout” in changeset wiki article).

$ wget -nv -O- --user=mikini --ask-password --post-data="<osmChange></osmChange>"
Password for user ‘mikini’: 
Authentication selected: Basic realm="Web Password", charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<diffResult version="0.6" generator="CGImap 0.8.3 (8531" copyright="OpenStreetMap and contributors"\
 attribution="" license=""/>
2020-07-25 14:27:20 URL: [278] -> "-" [1]

Procedure to change the building

The API’s “changeset/<changeset id>/upload” method supports only modifications encoded in the osmChange format which requires changes to be described as complete way/node/relation objects. That is, you can not ask the API to “add this tag to this way”, you need instead to describe the modified way completely saying “this way now looks like this”, including anything (like node references or existing tags) that was not modified. So to make a modificatino to the building’s way we need to retrieve the current version, modify it as needed and upload the complete new way.

Thus the procedure contains these steps;

  1. Retrieve current building (GET /way/*)
  2. Modify building data (locally)
  3. Amend changeset (POST /changeset/*/upload)

Retrieving current building (GET /way/*)

This can be done by issuing an unauthenticated GET request to the “/api/0.6/way/<way id>” endpoint.

The stdin splitter ‘tee’ is used here to both show the result in terminal and put it into file 185369466_v3.osc that we can use for amending the way with the wanted modifications.

$ wget -nv -O-|tee 185369466_v3.osc
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.8.3 (28697" copyright="OpenStreetMap and contributors"\
 attribution="" license="">
 <way id="185369466" visible="true" version="3" changeset="84400254" timestamp="2020-04-30T09:35:21Z" user="mikini" uid="2051">
  <nd ref="1959614623"/>
  <nd ref="1959614727"/>
  <nd ref="6299449794"/>
  <nd ref="1959614650"/>
  <nd ref="1959614630"/>
  <nd ref="6299449793"/>
  <nd ref="1959614765"/>
  <nd ref="7466482063"/>
  <nd ref="7466482064"/>
  <nd ref="7466482065"/>
  <nd ref="7466482062"/>
  <nd ref="1959614729"/>
  <nd ref="1959614623"/>
  <tag k="building" v="yes"/>
2020-07-25 14:54:30 URL: [769] -> "-" [1]

Modify building data (locally)

Now we need to build an osmChange file out of the existing <way>…</way> element from the output above describing the wanted building. This involves;

  1. removing the <xml> tag (maybe not needed, but it is not mentioned at all in the osmChange documentation)
  2. replacing <osm> with <osmChange>
  3. adding a <modify> element to the <osmChange> element, containing the existing <way>
  4. update the “changeset” attribute to the changeset we’re amending
  5. amending the contents of <way> with the wanted <tag>s

Use your favorite editor (emacs would be my preference) to load the 185369466_v3.osm file, make the modifications and save it as 185369466_v4.osc. OSM tags are a XML empty-element tags containing the OSM tag’s key and value in the “k” and “v” attributes, thus the “name” tag of the building I needed to add would be ‘<tag k=”name” v=”ISC Huset”/>’, I also added some other related tags (“source:name” and “website”).

The finished .osc file now looks like this;

$ cat 185369466_v4.osc
    <way id="185369466" visible="true" version="3" changeset="88490797" timestamp="2020-04-30T09:35:21Z" user="mikini" uid="2051">
      <nd ref="1959614623"/>
      <nd ref="1959614727"/>
      <nd ref="6299449794"/>
      <nd ref="1959614650"/>
      <nd ref="1959614630"/>
      <nd ref="6299449793"/>
      <nd ref="1959614765"/>
      <nd ref="7466482063"/>
      <nd ref="7466482064"/>
      <nd ref="7466482065"/>
      <nd ref="7466482062"/>
      <nd ref="1959614729"/>
      <nd ref="1959614623"/>
      <tag k="building" v="yes"/>
      <tag k="name" v="ISC Huset"/>
      <tag k="source:name" v="sign;website"/>
      <tag k="website" v=""/>

Wdiff’ing against the .osm source shows exactly what changed (additions between “{+” & “+}”, removals between “[-” & “-]”);

$ wdiff 185369466_v3.osm 185369466_v4.osc
[-<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.8.3 (28697" copyright="OpenStreetMap and contributors"\
 attribution="" license="">-]{+<osmChange>
    <way id="185369466" visible="true" version="3" [-changeset="84400254"-] {+changeset="88490797"+} timestamp="2020-04-30T09:35:21Z" user="mikini" uid="2051">
      <nd ref="1959614623"/>
      <nd ref="1959614727"/>
      <nd ref="6299449794"/>
      <nd ref="1959614650"/>
      <nd ref="1959614630"/>
      <nd ref="6299449793"/>
      <nd ref="1959614765"/>
      <nd ref="7466482063"/>
      <nd ref="7466482064"/>
      <nd ref="7466482065"/>
      <nd ref="7466482062"/>
      <nd ref="1959614729"/>
      <nd ref="1959614623"/>
      <tag k="building" v="yes"/>
      {+<tag k="name" v="ISC Huset"/>
      <tag k="source:name" v="sign;website"/>
      <tag k="website" v=""/>+}

Amend changeset (POST /changeset/*/upload)

Now, we’ll again use the changeset upload method but this time supplying our actual osmChange elemet in the .osc file.

The output is a bit elaborate, because I had enabled full output from wget while debugging what changes to the <way> element was needed for the server to accept the upload (only the “changeset” attribute needs to match the open changeset as outlined in the “Modify building data” above). I’ve highligted the actual server response telling that the changes were accepted and way #185369466 is now at v4.

$ wget -S -O- --user=mikini --ask-password --post-file=185369466_v4.osc
Password for user ‘mikini’: 
--2020-07-25 15:44:41--
Resolving (,,, ...
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 401 Unauthorized
  Date: Sat, 25 Jul 2020 13:44:41 GMT
  Server: Apache/2.4.29 (Ubuntu)
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  Expect-CT: max-age=0, report-uri=""
  WWW-Authenticate: Basic realm="Web Password", charset="UTF-8"
  Cache-Control: no-cache
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  Expect-CT: max-age=0, report-uri=""
  Content-Length: 22
  Content-Type: text/plain; charset=utf-8
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
Authentication selected: Basic realm="Web Password", charset="UTF-8"
Reusing existing connection to
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Sat, 25 Jul 2020 13:44:42 GMT
  Server: Apache/2.4.29 (Ubuntu)
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  Expect-CT: max-age=0, report-uri=""
  Content-Encoding: identity
  Cache-Control: private, max-age=0, must-revalidate
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  Expect-CT: max-age=0, report-uri=""
  Vary: Accept-Encoding
  Content-Type: application/xml; charset=utf-8
  Keep-Alive: timeout=5, max=99
  Connection: Keep-Alive
  Transfer-Encoding: chunked
Length: unspecified [application/xml]
Saving to: ‘STDOUT’
- [<=> ] 0 --.-KB/s
<?xml version="1.0" encoding="UTF-8"?>
<diffResult version="0.6" generator="CGImap 0.8.3 (8537" copyright="OpenStreetMap and contributors"\
 attribution="" license="">
 <way old_id="185369466" new_id="185369466" new_version="4"/>
- [ <=> ] 353 --.-KB/s in 0s

2020-07-25 15:44:42 (20,3 MB/s) - written to stdout [353]



That was it, the building is now named in OSM, in a changset amended by hand.

Take a look at

GitHub CLI on Ubuntu LTS (16.04 & 18.04)
Mar 4th, 2020 by miki

Inspired by a John Sullivan (of FSF) tweet asking about opinions on the new and shiny MS(TM) GitHub(TM) CLI(TM) tool named “gh”(TM) I wanted to try it out on one of my Ubuntu LTS systems (16.04).

I’ve always disliked the proprietary and centralised monoculture of github, especially after that thing with MS, so I’ve mostly avoided using the service for code I produce myself. If interested in independence and decentralisation maybe you should read up on that long fabled subject? Thus I’ve never even tried the predecessor “hub”(TM) tool (main page), and exactly how it differs from this new “CLI” thing is not obviously apparent from the communications.

Nevertheless, the “gh” tool, officially dubbed  GitHub CLI, being distributed under MIT license and written in go(lang) (afterwards, found out that this is indeed also applicable to the predecessing “hub” tool) made me curious enough to go see what they’re up to. Maybe its not that sinister a plot and they really just want to improve the independent and freely available mechanisms for source code storage, distribution and maintenance (I wish)?


A fairly recent (2019-09) version of go, >=1.13, is required so some gymnastics are needed to make stuff work on older distros like Ubuntu’s LTS (with 5 years support from Canonical). Anyway, this is what I did to build a useable “gh” ELF executable (20 MiB!, se below), this is from source, no precompiled stuff, no snaps. It was done on Ubuntu 16.04 (xenial) but I’ve been somewhat careful to inspect that things ought to be good for 18.04 (bionic) too. Non-essential output from the commands is largely discarded here. See Gory Details section below for the full monty.

Add go PPA & install packages

$ sudo add-apt-repository ppa:longsleep/golang-backports
$ sudo apt update
$ sudo apt install golang
$ go version
go version go1.13.4 linux/amd64

Clone repo & build

$ cd
$ git clone .githubcli
$ cd .githubcli
$ make

Setup PATH & test

$ echo 'export PATH="$HOME/.githubcli/bin:$PATH"' >> ~/.bash_profile
$ bash --login
$ gh
Work seamlessly with GitHub from the command line.

GitHub CLI is in early stages of development, and we'd love to hear your
feedback at <>

  gh [command]

Available Commands:
  help        Help about any command
  issue       Create and view issues
  pr          Create, view, and checkout pull requests
  repo        Create, clone, fork, and view repositories

      --help              Show help for command
  -R, --repo OWNER/REPO   Select another repository using the OWNER/REPO format
      --version           Show gh version

Use "gh [command] --help" for more information about a command.
subcommand is required

Trying it out

Randomly picked one of my few github repos, it contains some js experiments on parsing NMEA formatted coordinates, rather uninterestingly empty.


user@host:~$ gh repo clone mikini/coordinates 
Notice: authentication required
Press Enter to open in your browser... 

<auth session in browser>

Authentication complete. Press Enter to continue...

Cloning into 'coordinates'...
remote: Enumerating objects: 10, done.
remote: Total 10 (delta 0), reused 0 (delta 0), pack-reused 10
Unpacking objects: 100% (10/10), done.
Checking connectivity... done.

An ordinary OAuth request was spawned for authentication on The javascript executed in the browser seemed to interact with the gh tool through a local TCP connection on localhost:45454 which was the redirection target on authorisation (URL parameter: “redirect_uri=http://localhost:45454/callback”). The socket was rightfully not bound after the authentication had succeeded but this is definitely an attack vector, albeit hopefully only for locally running processes.

Listing issues & prs

user@host:~$ cd coordinates/
user@host:~$:~/coordinates$ gh issue list

Issues for mikini/coordinates

There are no open issues
miki@vcas-miki2:~/coordinates$ gh pr view
no open pull requests found for branch "master"

Creating issues

miki@vcas-miki2:~/coordinates$ gh issue create

Creating issue in mikini/coordinates

? Title Testing gh
? Body <Received>
? What's next? Preview in browser
Opening in your browser.

miki@vcas-miki2:~/coordinates$ gh issue create

Creating issue in mikini/coordinates

? Title Testing gh tool
? Body <Received>
? What's next? [Use arrows to move, type to filter]
> Preview in browser

On the first issue creation interaction I selected “preview in browser” which opened a draft issue in the browser, and dumped me back into the shell on the command line. The second interaction actually resulted in #1.

Gory Details

PPA options

The golang-backports PPA is maintained independently by Simon Eisenmann (credits: ~longsleep, @github, and carries packages up to:

There’s also an official PPA from the golang project (~gophers) which however only carries packages up to 1.11 for both.

Full (mostly) installation dump

Add go PPA, install packages

user@host:~$ sudo add-apt-repository ppa:longsleep/golang-backports
Golang 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 and 1.14 PPA for Ubuntu
 More info:
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmpvnuym97a/secring.gpg' created
gpg: keyring `/tmp/tmpvnuym97a/pubring.gpg' created
gpg: requesting key 56A3D45E from hkp server
gpg: /tmp/tmpvnuym97a/trustdb.gpg: trustdb created
gpg: key 56A3D45E: public key "Launchpad PPA for Simon Eisenmann" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

user@host:~$ sudo apt update
Hit:1 xenial InRelease
Get:2 xenial-updates InRelease [109 kB] 
Get:37 xenial-security/universe DEP-11 64x64 Icons [194 kB]
Get:38 xenial-security/multiverse amd64 DEP-11 Metadata [2.468 B]
Fetched 7.614 kB in 3s (2.346 kB/s) 
Reading package lists... Done
Building dependency tree 
Reading state information... Done
419 packages can be upgraded. Run 'apt list --upgradable' to see them.

user@host:~$ apt list --upgradeable golang -a
Listing... Done
golang/xenial,xenial 2:1.13~1longsleep1+xenial all [upgradable from: 2:1.6-1ubuntu4]
golang/xenial,xenial,now 2:1.6-1ubuntu4 all [installed,upgradable to: 2:1.13~1longsleep1+xenial]


user@host:~$ sudo apt install golang
Reading package lists... Done
Building dependency tree 
Reading state information... Done
The following packages were automatically installed and are no longer required:
golang-1.6 golang-1.6-doc golang-1.6-go golang-1.6-src
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
golang-1.13 golang-1.13-doc golang-1.13-go golang-1.13-src golang-doc golang-go golang-src
Recommended packages:
The following NEW packages will be installed
golang-1.13 golang-1.13-doc golang-1.13-go golang-1.13-src
The following packages will be upgraded:
golang golang-doc golang-go golang-src
4 to upgrade, 4 to newly install, 0 to remove and 413 not to upgrade.
Need to get 60,2 MB of archives.
After this operation, 322 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 xenial/main amd64 golang-1.13-src amd64 1.13.4-1longsleep1+xenial [12,7 MB]
Get:2 xenial/main amd64 golang-1.13-go amd64 1.13.4-1longsleep1+xenial [44,9 MB]
Get:3 xenial/main amd64 golang-1.13-doc all 1.13.4-1longsleep1+xenial [2.542 kB]
Get:4 xenial/main amd64 golang-1.13 all 1.13.4-1longsleep1+xenial [25,2 kB]
Get:5 xenial/main amd64 golang-src amd64 2:1.13~1longsleep1+xenial [3.838 B]
Get:6 xenial/main amd64 golang-go amd64 2:1.13~1longsleep1+xenial [23,0 kB]
Get:7 xenial/main amd64 golang-doc all 2:1.13~1longsleep1+xenial [3.880 B]
Get:8 xenial/main amd64 golang all 2:1.13~1longsleep1+xenial [3.826 B]
Fetched 60,2 MB in 5s (10,8 MB/s) 
Selecting previously unselected package golang-1.13-src.
(Reading database ... 460737 files and directories currently installed.)
Preparing to unpack .../golang-1.13-src_1.13.4-1longsleep1+xenial_amd64.deb ...
Unpacking golang-1.13-src (1.13.4-1longsleep1+xenial) ...
Selecting previously unselected package golang-1.13-go.
Preparing to unpack .../golang-1.13-go_1.13.4-1longsleep1+xenial_amd64.deb ...
Unpacking golang-1.13-go (1.13.4-1longsleep1+xenial) ...
Selecting previously unselected package golang-1.13-doc.
Preparing to unpack .../golang-1.13-doc_1.13.4-1longsleep1+xenial_all.deb ...
Unpacking golang-1.13-doc (1.13.4-1longsleep1+xenial) ...
Selecting previously unselected package golang-1.13.
Preparing to unpack .../golang-1.13_1.13.4-1longsleep1+xenial_all.deb ...
Unpacking golang-1.13 (1.13.4-1longsleep1+xenial) ...
Preparing to unpack .../golang-src_2%3a1.13~1longsleep1+xenial_amd64.deb ...
Unpacking golang-src (2:1.13~1longsleep1+xenial) over (2:1.6-1ubuntu4) ...
Preparing to unpack .../golang-go_2%3a1.13~1longsleep1+xenial_amd64.deb ...
Unpacking golang-go (2:1.13~1longsleep1+xenial) over (2:1.6-1ubuntu4) ...
Preparing to unpack .../golang-doc_2%3a1.13~1longsleep1+xenial_all.deb ...
Unpacking golang-doc (2:1.13~1longsleep1+xenial) over (2:1.6-1ubuntu4) ...
Preparing to unpack .../golang_2%3a1.13~1longsleep1+xenial_all.deb ...
Unpacking golang (2:1.13~1longsleep1+xenial) over (2:1.6-1ubuntu4) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up golang-1.13-src (1.13.4-1longsleep1+xenial) ...
Setting up golang-1.13-go (1.13.4-1longsleep1+xenial) ...
Setting up golang-1.13-doc (1.13.4-1longsleep1+xenial) ...
Setting up golang-1.13 (1.13.4-1longsleep1+xenial) ...
Setting up golang-src (2:1.13~1longsleep1+xenial) ...
Setting up golang-go (2:1.13~1longsleep1+xenial) ...
Setting up golang-doc (2:1.13~1longsleep1+xenial) ...
Setting up golang (2:1.13~1longsleep1+xenial) ...

user@host:~$ go version
go version go1.13.4 linux/amd64

Clone repo & build

user@host:~$ git clone .githubcli
Cloning into '.githubcli'...
remote: Enumerating objects: 168, done.
remote: Counting objects: 100% (168/168), done.
remote: Compressing objects: 100% (100/100), done.
remote: Total 5577 (delta 93), reused 122 (delta 67), pack-reused 5409
Receiving objects: 100% (5577/5577), 7.53 MiB | 2.61 MiB/s, done.
Resolving deltas: 100% (3269/3269), done.
Checking connectivity... done.

user@host:~$ cd .githubcli
user@host:~/.githubcli (master=)$ make
go: downloading v0.0.0-20191202100458-e7afc7fbc510
go: downloading v1.1.0
go: downloading v0.1.6
go: downloading v0.0.6
go: downloading v3.0.0-20200121175148-a6ecf24a6d71
go: downloading v0.0.12
go: downloading v0.3.2
go: extracting v1.1.0
go: extracting v0.1.6
go: extracting v0.0.0-20191202100458-e7afc7fbc510
go: extracting v0.0.6
go: extracting v0.0.12
go: downloading v0.0.0-20200223170610-d5e6a3e2c0ae
go: downloading v0.0.0-20200219234226-1ad67e1f0ef4
go: downloading v0.0.0-20170206155736-9520e82c474b
go: downloading v1.9.0
go: extracting v3.0.0-20200121175148-a6ecf24a6d71
go: downloading v1.2.0
go: downloading v1.0.5
go: downloading v2.0.7
go: downloading v0.0.0-20180428030007-95032a82bc51
go: downloading v0.1.1-0.20200304134224-7e5c90143acc
go: extracting v0.0.0-20170206155736-9520e82c474b
go: extracting v1.0.5
go: extracting v1.2.0
go: downloading v2.2.8
go: downloading v2.0.0
go: downloading v0.0.4
go: extracting v0.0.0-20180428030007-95032a82bc51
go: extracting v1.9.0
go: extracting v2.0.7
go: downloading v1.7.0
go: extracting v0.1.1-0.20200304134224-7e5c90143acc
go: downloading v1.1.24
go: downloading v1.0.2
go: extracting v2.2.8
go: extracting v0.0.4
go: downloading v0.0.4
go: downloading v0.1.0
go: extracting v1.7.0
go: extracting v1.0.2
go: extracting v2.0.0
go: extracting v0.0.0-20200223170610-d5e6a3e2c0ae
go: extracting v0.1.0
go: extracting v0.0.4
go: downloading v0.0.0-20200219183655-46282727080f
go: extracting v1.1.24
go: downloading v0.7.2-0.20200304075647-34d9c7143bf5
go: downloading v0.0.8
go: downloading v0.4.0
go: downloading v2.0.1
go: extracting v0.0.0-20200219234226-1ad67e1f0ef4
go: extracting v0.0.8
go: extracting v2.0.1
go: downloading v1.0.0
go: extracting v0.7.2-0.20200304075647-34d9c7143bf5
go: extracting v1.0.0
go: extracting v0.4.0
go: downloading v1.2.0
go: downloading v1.0.3
go: downloading v0.0.0-20190703233501-fc88cf888a3f
go: downloading v0.0.0-20160403171240-cbb64ac3d964
go: extracting v0.3.2
go: extracting v0.0.0-20190703233501-fc88cf888a3f
go: extracting v0.0.0-20160403171240-cbb64ac3d964
go: extracting v0.0.0-20200219183655-46282727080f
go: extracting v1.0.3
go: extracting v1.2.0
go: finding v0.0.6
go: finding v2.0.7
go: finding v0.0.4
go: finding v0.0.0-20191202100458-e7afc7fbc510
go: finding v0.0.0-20170206155736-9520e82c474b
go: finding v3.0.0-20200121175148-a6ecf24a6d71
go: finding v1.0.5
go: finding v1.2.0
go: finding v1.1.0
go: finding v1.9.0
go: finding v0.3.2
go: finding v2.0.0
go: finding v0.1.1-0.20200304134224-7e5c90143acc
go: finding v0.0.0-20180428030007-95032a82bc51
go: finding v0.1.6
go: finding v2.2.8
go: finding v2.0.1
go: finding v0.0.12
go: finding v1.7.0
go: finding v0.0.0-20200219234226-1ad67e1f0ef4
go: finding v0.4.0
go: finding v0.0.0-20200223170610-d5e6a3e2c0ae
go: finding v1.0.0
go: finding v1.1.24
go: finding v0.7.2-0.20200304075647-34d9c7143bf5
go: finding v0.0.0-20190703233501-fc88cf888a3f
go: finding v1.2.0
go: finding v1.0.3
go: finding v0.1.0
go: finding v1.0.2
go: finding v0.0.0-20160403171240-cbb64ac3d964
go: finding v0.0.4
go: finding v0.0.8
go: finding v0.0.0-20200219183655-46282727080f
user@host:~/.githubcli (master=)$ 

Cursory inspection of exec

user@host:~/.githubcli (master=)$ ls -l bin/gh
-rwxrwxr-x 1 user user 21097487 Mar  4 18:03 bin/gh
user@host:~/.githubcli (master=)$ 

user@host:~/.githubcli (master=)$ file bin/gh
bin/gh: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, not stripped
user@host:~/.githubcli (master=)$ 

user@host:~/.githubcli (master=)$ ldd bin/gh =>  (0x00007ffdc4329000) => /lib/x86_64-linux-gnu/ (0x00007fb1018c2000) => /lib/x86_64-linux-gnu/ (0x00007fb1014f8000)
	/lib64/ (0x00007fb101adf000)
user@host:~/.githubcli (master=)$ 

user@host:~/.githubcli (master=)$ nm -D bin/gh
                 U abort
00000000004fd140 T _cgo_panic
000000000045bf10 T _cgo_topofstack
00000000004fd190 T crosscall2
                 U __errno_location
                 U __fprintf_chk
                 U fputc
                 U free
                 U freeaddrinfo
                 U fwrite
                 U gai_strerror
                 U getaddrinfo
                 U getnameinfo
                 U malloc
                 U mmap
                 U munmap
                 U nanosleep
                 U pthread_attr_destroy
                 U pthread_attr_getstacksize
                 U pthread_attr_init
                 U pthread_cond_broadcast
                 U pthread_cond_wait
                 U pthread_create
                 U pthread_detach
                 U pthread_mutex_lock
                 U pthread_mutex_unlock
                 U pthread_sigmask
                 U setenv
                 U sigaction
                 U sigaddset
                 U sigemptyset
                 U sigfillset
                 U sigismember
                 U __stack_chk_fail
                 U stderr
                 U strerror
                 U unsetenv
                 U __vfprintf_chk
user@host:~/.githubcli (master=)$ 

Setup PATH & test

user@host:~/.githubcli (master=)$ cd
user@host:~$ echo 'export PATH="$HOME/.githubcli/bin:$PATH"' >> ~/.bash_profile
user@host:~$ bash --login
user@host:~$ gh
Work seamlessly with GitHub from the command line.

GitHub CLI is in early stages of development, and we'd love to hear your
feedback at <>

  gh [command]

Available Commands:
  help        Help about any command
  issue       Create and view issues
  pr          Create, view, and checkout pull requests
  repo        Create, clone, fork, and view repositories

      --help              Show help for command
  -R, --repo OWNER/REPO   Select another repository using the OWNER/REPO format
      --version           Show gh version

Use "gh [command] --help" for more information about a command.
subcommand is required
A havfrue stopping by?: Deep Energy pipelay vessel in Esbjerg
Oct 2nd, 2019 by miki

Came by Esbjerg Harbour on September 24th 2019 and saw what was obviously a cable ship docked at the quay. A giant ship and I immediately thought that the mermaid might be closing in on Jutland. Some quick drive-by pictures and vessel details below:


New sighting on 2019-11-03:

JV article about ship and ongoing upgrades causing noise.

Ubuntu 18.04 Tweaks for a 16.04 User
Jun 24th, 2019 by miki

This post will detail some stuff I’ve done to a plain Ubuntu 18.04 Desktop (bionic) to make me feel a little more at home in the transition from my daily driver for years the 16.04 release using Canoncial’s Unity as the primary desktop interface to the GNOME Shell of 18.04. Canonical abandoned the former after shifting focus from the convergence and personal device market to cloud and IoT in 2017 leaving development of its mobile OS, Ubuntu Touch which Unity is a part of, to the community formed UBports project (Unity8 is now known as Lomiri). I’ve been putting off this transition exactly because I knew it would require me to make some tweaks to my daily routines, but this system is not one I use on a daily basis so it will make the transition a gentle ride.

The intention is to update this as the experience progresses.

EDIT 2021-08-25: clean up and publish dormant draft post

Browsing GNOME Extensions

To be able to install GNOME Extensions directly from a browser while perusing the directory at, add the GNOME Shell Integration extension/add-on to your browser (Firefox add-on, Chrome Web Store), then install the Integration extension in GNOME to communicate with the browser extension:

sudo apt install chrome-gnome-shell

After this you can go to to see, configure and update installed extensions.

Useful GNOME Extensions

Time Keeping

World/Alarm/Stopwatch/Timer application

GNOME includes a nice Clock application which is available in the package repository but not installed by default;

sudo apt install gnome-clocks

Installing the Alarm Clock extension described above, will also show the application’s alarms in the notification area.

Notification bar

I like both the date and seconds to be displayed in the head of the desktop, so to format the text a couple of extensions are available;

Itch: eog core dump on Galaxy 7 panorama image
Jun 10th, 2019 by miki

  • Took some photos with my Galaxy 7. Some were panoramas.
  • EOG crashed while loading them.
  • Memory was low.
  • Maybe related to previously experienced missing EOI marker issue with Samsung camera application.

Will investigate later and amend the post (promise!).

Commandline Dump

$ free; find . -size +25M -exec bash -c 'ls -l {}; eog {}; echo' \;; free
              total        used        free      shared  buff/cache   available
Mem:        7746692     5767656      843228      317764     1135808     1271048
Swap:       7950332     5113012     2837320
-rw-rw-r-- 1 miki miki 39926496 Jun 10 19:25 ./20190609_184124.jpg

** (eog:23320): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed
eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed.
bash: line 1: 23320 Aborted                 (core dumped) eog ./20190609_184124.jpg

-rw-rw-r-- 1 miki miki 38286099 Jun 10 19:26 ./20190609_183714.jpg

** (eog:23332): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed
eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed.
bash: line 1: 23332 Aborted                 (core dumped) eog ./20190609_183714.jpg

-rw-rw-r-- 1 miki miki 36181801 Jun  9 17:13 ./20190609_160437.jpg

** (eog:23343): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed

** (eog:23343): CRITICAL **: eog_reload_plugin_deactivate: assertion 'G_IS_MENU (menu)' failed

-rw-rw-r-- 1 miki miki 39059177 Jun 10 19:25 ./20190609_184146.jpg

** (eog:23354): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed
eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed.
bash: line 1: 23354 Aborted                 (core dumped) eog ./20190609_184146.jpg

              total        used        free      shared  buff/cache   available
Mem:        7746692     5773448      495604      659944     1477640      922956
Swap:       7950332     5112700     2837632


»  Substance:WordPress   »  Style:Ahren Ahimsa
© 2021 Mikkel Kirkgaard Nielsen, contents CC BY-SA 4.0