Recent Changes

Here is the list of recent changes at this site.

Updates in the last 30 days

1 | 3 | 7 | 30 | 90 days
List all changes Include rollbacks Include minor changes
List later changes RSS RSS with pages RSS with pages and diff


  • 06:20 UTC (new) (history) 2020-06-01 Node modules working as command-line scripts . . . . mbork Recently, I wanted to run one Node.JS CLI script from another. Of course, being in a hurry and KISS and whatnot, I decided to just use child_process.execFileSync with node as the first argument, but this is of course grossly inefficient. What if I could write a module usable both from the command line and other code? Well, it turns out that not only is this doable, but actually easy and robust.


  • 08:17 UTC (new) (history) 2020-05-24 Two parameters and at least one required in yargs . . . . mbork I happen to write shell scripts in Node.JS quite often. They usually consume some kind of command-line agruments, and my library of choice to parse them is yargs. Recently, I had a situation where there were two parameters and it was required that one of them is given. A bit surprisingly, yargs does not seem to have an option requiredAlternative or something that says “of the following two parameters, at least one must be given” (it has a conflicts method and option, either of which can be used to say “of these two parameters, at most one may be given”, though). Happily, there is a simple way to enforce such a requiement due to the quite general “check” method.


  • 20:19 UTC (new) (history) 2020-05-18 entr, a wrapper around inotify . . . . mbork Shortly after my post from last year describing how I use inotifywait to start programs on file change, one of the readers emailed me about an utility called entr. It is an extremely simple-to-use tool which just gets the filelist to watch on stdin and a command to execute when any of the files changes as CLI arguments – and that’s pretty much it. (That does not imply it is simplistic – according to its website, it performs some non-trivial stuff under the hood.) Thanks!


  • 20:37 UTC (new) (history) 2020-05-11 Diffing and font-lock . . . . mbork I often work with diffs in Emacs. I usually do that within Magit, which highlights diffs in the usual way (highlighting deleted lines with reddish background, inserted lines with greenish background, and the deleted/inserted characters within these lines with slightly more prominent versions of the same colors). However, I sometimes use plain Emacs diff (e.g. to compare two fles not kept in Git), and I noticed an annoying thing: diff’s font-lock is applied on top of the usual font-lock, depending on the files’ syntax. While in general this seems resonable, in the case of LaTeX files in AUCTeX (where the font lock colors are especially diverse) this makes the diff completely unreadable. I was pretty sure that disabling the syntax font-lock would reduce the visual noise of the diffs.