MXIi

making sense of things

A case of adapting a CLI test command from *NIX to Windows

There is a package I wanted to publish to npmjs.com. That package provides a CLI tool among other features, and contains tests for that tool. Unfortunately, tests were made with only *NIX in mind, so it wasn’t possible to pass all tests and publish the package from Windows.

The main culprit is inside the following function:

function runWithInputAndExpect (input, args, expectedOutput, done) {
  var command = 'echo "' + input.replace(/"/g, '\\"') + '" | node bin/cli.js ' + args;
  exec(command, function callback (error, stdout, stderr) {
    expect(error).to.be.a('null');
    expect(stderr).to.equal('');
    expect(stdout).to.equal(expectedOutput + '\n');
    done(error);
  });
}

What makes the difference between *NIX and Windows (as far as we concerned here) is how echo command works. First of all, it keeps the quotes! But after we try to remove them - we will soon discover that the rabbit hole might be quite deep.

And down the rabbit hole we go:

SDRSharp plugin for touch devices, some thoughts on license

This project was sitting on my hard drive for several years until now. Last time I made an attempt to clean it up and prepare for publishing to GitHub in 2017.

Making sure it compiles agains all required targets and contains all the required notes - is easy for such a small project. But there was something I just didn’t know how to deal with… More on this below.

Frequency Navigation plugin screenshot

Back in time, I was playing with RTL-SDR dongles, and the device I was connecting them to was a Microsoft Surface 2 Pro - “laptop-but-more-like-a-tablet”. I love Microsoft Surface devices, especially that old one, for it’s compact size. It is really cool to be able to move around freely, listening what’s coming from a dongle, no awkward balancing acts with a classic laptop…

Portable use has some UX specifics. Namely, having to use keyboard and mouse is really limiting, and touch screen operation on a tablet device is much more preferred.

While SDR# had quite clean UI, it was clearly made without such considerations. The core functionality - frequency navigation - was nearly impossible to perform on the go. It is really hard to hit top or bottom of the right digit on the frequency display.

At the same time, I had some examples of test and measurement equipment in access. These are historically made with very good tactile operation in mind. So I figured I can bring some of that experience to a SDR# plugin.

Next folder, previous folder navigation in Explorer with QTTabBar

QTTabBar surprised us with the update recently, after almost three years of silence. (The changelog also points to an importance of having a full copy of your code somewhere outside of your PC. Version control systems to the rescue.)

To celebrate this fact, I decided to publish a little custom feature I’m using with QTTabBar — a script and UI buttons to navigate between folders within one common parent folder.

There are cases when you need to visit a set of folders, and goind up and down in the folder structure is getting tedious. That’s where magic “Next folder”, “Previous folder” buttons come in handy.

Navigation pane, a.k.a. tree view can, in principle, be used for that, but it isn’t always convenient to use. I can only use it for top level navigation, unless Microsoft will come up with some way to reduce clutter in the tree - not showing subfolders that aren’t ascentants or descendants of current folder for example.

My QTTabBar panel looks like this:

QTTabBar panel screenshot

Two triangles looking in opposite directions are the buttons this post is dedicated to.

Below is the code and description for the buttons.

PowerShell, square brackets and apostrophes

This is a follow-up post to the one about square brackets and Unicode in PowerShell.

I discovered recently that there is another PITA character that interferes with my workaround — it’s a single quote, or apostrophe.

It’s fine to start PowerShell inside a folder with an apostrophe in its name, but we have to escape it when using inside Powershell commands or passing into PowerShell from anywhere else.

Below are my experiments to find the best way to open PowerShell in any folder… if ever possible.

JavaScript spoiler with a twist (collapsing up or down)

I thought that I will eventually need to use spoilers in this blog to hide long and optional blocks of text. And at the same time I’m often unhappy with collapsible block implementations across the Internet.

So I decided to design my own spoiler with one useful feature: it can be collapsed not only from the top edge but also from the bottom edge — you will not lose the line you were reading and you don’t have to scroll all the way to the beginning of the spoiler.

Examples:

click to showhide

This spoiler can be expanded up and down. And your mouse is left right over the button you just pressed whenever it is possible (on top and bottom of a page there may be not enough stuff to keep it so, obviously).

click to showhide
click to showhide

This spoiler can be expanded in one direction only. Collapsing behaviour is still the same. The difference is just a few lines in CSS.

click to showhide

Keep reading to see how it is done.

PowerShell, Explorer, square brackets and Unicode paths

Let’s make a folder C:\[test] and try to open PowerShell there from Explorer (using Ribbon or context menu).

set-location: Cannot find path 'C:[test]' because it does not exist. At line:1 char:1

Oops!

Let’s see what we can do with this.