The End

The time is past

  the bell has rung

The deeds to do

  that have been done

    are gathered up

      into the store

The rest: undone,

  for ever more

(C) Sam Liddicott 2016

Calibri and Cambria on Linux

I'm no font fanatic. I can't tell the difference between Calibri and Carlito but I can tell the a busted document layout.

Fortunately, Carlito has the same front metrics as Calibiri (and Caladea has the same metrics as Cambria).

The font-substitution table in LibreOffice then allows me to work on documents using these fonts while getting a layout the same as my colleagues on Microsoft Office.

Quoting from the Debian Wiki:

LibreOffice font substitution

To install them, issue these commands as root in a shell:

# apt-get update
# apt-get install fonts-crosextra-carlito fonts-crosextra-caladea

In LibreOffice, you exchange Calibri and Cambria with Carlito and Caladea this way:

• Open the "Extras" menu
• Go to "Options"
• Choose "LibreOffice"
• Choose "Fonts"
• Define a substitution for each of the two fonts (Calibri -> Carlito, Cambria -> Caladea).
• Remember to check "Always" in the substitution lines.

Once the program is restarted, documents sent from MS Office look almost the same on your screen and printouts.

async promises - just in time to be late for the node.js show

I'm late to the node.js show; and that's a good thing.

It means I don't have to worry about CPS callback hell

do_something(..., function(err, result) {
   something_else(result);
});

I means I don't even have to do much overt promising

do_something(...).then( (r) => {
  something_else(result);
}).catch( (e) => {
  ...
});

I can just use async/await with automatic exception propagation.

return await do_something(...);

I'm not averse to the odd promise for the interface between an old-style CPS function; after all only an async function can call await. But an async function is also a promise. So I can convert this:

function expressHandler(req, res, next) {
  do_something(..., function(err, result) {
    if (err) return next(err); // return avoids else
  ...
    next();
  });
} 
...
function do_something(..., callback) {
  try {
  ...
  return callback(undefined, result);
} catch (e) {
  return callback(e);
}

into

function expressHandler(req, res, next) {
  do_something(...).then((r) => {
    ...
    next();
  }).catch(next);
}
...
async function do_something(...) {
  return await something_else(...);
}

do_something is called as a promise and can be an async function that can await on other async functions or on promises. Async functions all the way up; callbacks all the way down (where I can't see).

Windows 10 DNS Suffixes

To fix the problem of domain suffixes being applied to well-dotted fqdn:

http://superuser.com/a/680359/638934
combined with

The group policy reg keys for the searchlist are:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\"SearchList"="domain1,domain2,domain3"
and
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows NT\DNSClient\"SearchList"="domain1,domain2,domain3"

https://social.technet.microsoft.com/Forums/windows/en-US/76d07f31-62d6-4648-a3e2-7e6e16791363/append-these-dns-suffixes-not-available?forum=w7itpronetworking

Use these tricks to prefix: .,
(dot comma) to the front of the search list.

Thus each name will be tried in it's current form without any other domain suffixes first.

And so a well-dotted fqdn will resolve.

Defining bash functions in a Makefile

As I answered here; a makefile recipe may depend on bash functions rather than bash scripts.

Because of bash's export -f function-name feature to export a bash function definition into the environment where it will be picked up by sub-child invocations of bash, we can define a bash variable in the environment in the same form in the Makefile.

If we define bash functions in the Makefile using the same format bash does, and export them into the environment, and set SHELL=bash then we can use these bash functions in the make recipe.

Let's see how bash formats functions exported in the environment:

$ # define the function
$ something() { echo do something here ; }
$ export -f something

$ # the Makefile
$ cat > Makefile <<END
SHELL=bash
all: ; something
END
$

Try it out

$ make
something
do something here
$

How does this look in the environment?

$ env | grep something
BASH_FUNC_something%%=() { echo do something here

The pattern is (currently):
  BASH_FUNC_function-name%%=() { function-body }

So we do this in the Makefile:

SHELL=bash
define BASH_FUNC_something-else%%
() {
  echo something else
}
endef
export BASH_FUNC_something-else%%

all: ; something-else

and try it:

$ make
something-else
something else

It's a bit ugly in the Makefile but presents no ugliness for make -n

Parsing paths & deleting empty items from a bash list

This spell will split a path into directories:

IFS=/ read -d "" -r -a path <<<"$path"

but because of the action of <<<, the final item will have a newline appended -- but that can be removed thus:

path[-1]="${path[-1]%$'\n'}"

If the path began with a /, then path[0] will be empty, so as the leading / is important, we'll recover that

test -z "${path[0]}" && path[0]="/"

This spell will remove empty items from the list (and also renumber the indexes):

IFS= eval 'path=(${path[@]})'

(We could avoid the eval by saving IFS, but eval is safe enough here not to bother).

Now it is simple enough to iterate over "${path[@]}" and perform a chdir on each stage.

Update on old DisplayLink drivers

An update on my earlier post of 2012.

Driver 1.1.62 (15 May 2016) is now available at http://www.displaylink.com/downloads/ubuntu and does not require any fixups for wrong USB vendor ID numbers, or patches for kernels > 4.5.0

For my HP displaylink hub I have:

/etc/udev/rules.d/50-displaylink.rules:

# DisplayLink devices always have the active configuration on configuration #1
ATTR{idVendor}=="17e9", ATTR{idProduct}=="01d4", RUN+="/usr/bin/dlconfig"

and /usr/bin/dlconfig:

#! /bin/bash

echo 1 > "/sys/$DEVPATH/bConfigurationValue"

However, I must insert the USB device AFTER logging into to X or I get two fb devices added, one owned by udl and one by evdi. I suspect this is a race condition problem.

In any case, none of it works for me -- I'm not able to view anything at all on the frame buffer. I guess my USB device is too old.

However, if I modprobe udlfb and ignore the evdi drivers, and udl then I at least get a working framebuffer that can display images with fbi. -- but the colour depth is stuck at 16.

I'm able to use it as a primary device for an X11 session with this /etc/X11/xorg.conf

Section "ServerLayout"
    Identifier     "X.org Configured"
    Screen      0  "Screen0" 0 0
    InputDevice    "Mouse0" "CorePointer"
    InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "glx"
EndSection

Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "auto"
    Option        "Device" "/dev/input/mice"
    Option        "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
    Identifier  "Card1"
    Driver    "fbdev"
    BusID    "USB"
    Option    "fbdev"    "/dev/fb1"
    Option    "ReportDamage"    "true"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card1"
    Monitor    "Monitor0"
    DefaultDepth    16
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
EndSection