One of the things I sometimes find quite frustrating about vim is that the standard textwidth and wrap options imply assumptions about whether a text-style file (.txt, .md, READMEs, etc.) have “hard” carriage returns (where paragraphs are wrapped with actual carriage returns) or “soft” (where paragraphs are wrapped dynamically by the editor). When you create your own files, you’ll probably have your own preference for which of these you do, but when you are working with files that come from others, it’s very useful to have the ability to quickly switch between them.
To help address this problem, I’m constructing a new Vim plugin - vim-wrapping-softhard. The README should hopefully be self-explanatory in installing and using it.
If you’re anything like me, you like fzf, you like zsh, and you oh-my-zsh’s z plugin.
However, although the z plugin does a great job of allowing you to switch between frequently-used directories just by typing z *somedirectorysubstring*, it doesn’t really easily allow you to browse those directories, with partial-string search.
I’ve written a zsh plugin which brings together the z plugin and fzf to allow you to easily browse recently used directories at any point on the command line. It’s hosted on GitHub - find out more there.
I’ve been working with Docker a lot recently, and have been switching to non-root users within the Dockerfile using the USER instruction (not for security reasons, but in order to test software not as root). As a result, I’ve been suffering a little from this issue - essentially, files copied into a Docker image using ADD or COPY are copied with the owner as root, irrespective of the ownership outside the Docker image. According to this comment, this behaviour in Dockerfiles won’t change, at least in the near future.
Irrespective of the merits of this, I needed a solution. There is an (inelegant) way to work around this, which is to switch to root, copy the file in, change its ownership, and switch back to a regular user. I could do this directly inside the Dockerfile, but this requires a lot of extra boilerplate code bulking out the Dockerfile.
As a result, I turned to an ancient templating technology to make my Dockerfile more manageable - m4. I’ve created an m4 macro file which can be included in a Dockerfile. The full version (called docker-copy-as-user) is on github, but a small flavour is:
COPY $1 $2
RUN chown testuser $2/$1
A file that contains this macro can be included in a Dockerfile (which I now like to call Dockerfile.m4) with the incantation include(`docker-copy-as-user'). This can then be used by including the ‘meta-instruction’ COPYASUSER filename target/dir user-to-own-it. For example, Dockerfile.m4 might look like:
This can then be pre-processed before you run docker build with:
Note: I am very much a newbie to both Docker and m4. Please don’t read the above as being the optimal answer. In particular, your final (processed) Dockerfile still ends up pretty bulky, so this will still have performance implications due to the number of layers. I’d be glad to hear any suggested improvements.
Based on my previous post about getting my Logitech R800 presenting tool working with Keynote using Karabiner, I’ve now spent some time extending my private.xml to add support for QuickTime Player also. It now supports (inside QuickTime Player):
Left: Rewind the video at various speeds.
Right: Fast-forward the video at various speeds.
“Start presentation”: Go into fullscreen.
“Blank presentation”: Pause/play presentation.
This is very useful when giving a “live” demo from a QuickTime video, as you can pause/play/rewind etc. all from the presenter tool.
I was recently looking for a way to support building a basic Debian package for email2pdf - a fairly simple Python program I maintain. In particular, I wanted to:
Keep the Debian build process simple - its packaging has always been a bit of a mystery to me.
Ensure that the git revision was in some way reflected in the Debian version number in a mostlymonotonic way, which solely the git revision would not, since it’s merely a SHA1 hash.
The first bit turned out to be easier than I thought, since it turns out all you really need for a basic Debian package is a control file that looks a bit like this (for the moment, this assumes a version number hardcoded in this file):
Depends: some, other, debian-packages
Maintainer: Andrew Ferrier <firstname.lastname@example.org>
Description: Some short description
A much longer description that goes on for ages and ages and ages.
Once you have that, you put it in a directory tree called DEBIAN/, together with any files you want to put in the package, and run dpkg-deb --build at the root of it. For example:
(You can see a fuller example here in the builddeb_real target here).
However, the second part - to determine an appropriate version string for the Debian package - was fiddlier. Eventually, I settled on a similar technique to the one described here.
However, rather than git describe --tags --long, as recommended in the answer, I instead use git describe --dirty. This has the following advantages:
It ensures that if a Debian package is produced during development, when the git tree might be dirty, that -dirty is appended to the package version to distinguish it from a non-dirty one.
Not using --tags means that lightweight (non-annotated tags) are not used, which means we can use lightweight tags for miscellaneous purposes, and use annotated tags only for “released” versions of the software. In general, I only push annotated tags up to github.com repositories (this then integrates nicely with GitHub’s “Releases” concept).
Not using --long means that ‘released’ versions (where the current commit exactly matches an annotated tag) have a clean and well-defined version string, like ‘0.9’. Commits that don’t have an associated annotated tag have a commit string like ‘0.9-12-gf385006’, so the second number (‘12’ in this case) is the number of commits since ‘0.9’, and hence monotonically increases. The short commit ID (‘gf385006’) makes it easier to locate the exact version from the Debian package in git.
Once we have a way to determine the version string (git describe --dirty), now we need a way to get this into the Debian package control file. This can be done with a simple sed script:
control_template is basically a template-ized version of control, where the Version field contains a placeholder (see the real version from email2pdf as an example).
Once the above sed command has been executed, the dpkg-deb --build command can be executed as above.