Tuesday, February 22, 2022

Canadians! How to turn off that annoying "Control-Shift" Keyboard Switch

No offense to mon copains Quebecois (did I say that right?), but a particular quirk affects PCs for a unilinguist Anglo like me when the Region setting in Windows is set to Canada (or I suppose any bilingual country). 

I've had the annoying experience of holding down "Control-Shift" for more than a couple of seconds, say while I'm trying to decide if I want to paste plain text into a Google Chrome field (using Ctrl-Shift-V), then suddenly I'm getting accented characters all over the place. 

This is Windows being helpful to us Canucks, by switching the keyboard layout from Canadian English to Canadian French, which would be great, if a) I had a Canadian French keyboard, and b) I knew how to write in Canadian French on that keyboard, and c) I actually wanted to write in Canadian French!

Well, I discovered how to turn off that 'helpful' keyboard shift:

  1. Open Settings and search for "advanced keyboard settings":

  2. In the Advanced Keyboard Settings panel, click on Language bar options:
  3. In the Text Services and Input Languages control panel, select the "Advanced Key Settings" tab and click the "Change Key Sequence" button:

  4. Finally we are there: click the "Not Assigned" radio buttons for either or both "Switch Input Language" or "Switch Keyboard Layout" options:
And that I think is it!

Wednesday, June 23, 2021

Using Windows Command Line to make a dummy file

Echo 64 bytes to a seed file: 

C:\Temp>echo This is just a sample line appended to create a bi wefhwef weh> dummy8.txt

Then call 'type' in a for loop to append the contents of the file to itself:

C:\Temp>for /L %i in (1,1,8) do type dummy.txt >> dummy.txt

Makes a  32,768 byte (32Kb) file.

Courtesy https://www.windows-commandline.com/how-to-create-large-dummy-file/

Tuesday, June 8, 2021

Formatting Time and Date with Perl

# timestamp examples
use strict;
use warnings;
use v5.10.0;

use POSIX qq(strftime);

my $timestamp = strftime("%Y-%m-%d_%a_%H-%M-%S",localtime);

say $timestamp; # 2021-06-08_Tue_11-54-28

# ------------------------------------------------------------------------------

use DateTime;

my $today = DateTime->today();

say $today; # 2021-06-08T00:00:00

say $today->date; # 2021-06-08

Wednesday, November 4, 2020

Extensions for Perl in VS Code

Extension for Perl that work reasonably well in Visual Studio Code

Sunday, June 7, 2020

The Safe Way to test Thermal Runaway Protection on 3D Printers

  1. Disconnect the heater cartridge from the main board
  2. Start heating the hot end
  3. Expect machine to error out after ~10 seconds and shut down 

Thursday, May 28, 2020

Writing useful commit comments

Some thoughts on writing useful [concise, descriptive, contextual] commit comments. Applies to all SCM systems (Git, Subversion, etc.)

A properly formed Git commit subject line should always be able to complete the following sentence:

  • If applied, this commit will your subject line here
For example:
  • If applied, this commit will refactor subsystem X for readability
  • If applied, this commit will update getting started documentation
  • If applied, this commit will remove deprecated methods
  • If applied, this commit will release version 1.0.0
  • If applied, this commit will merge pull request #123 from user/branch
Chris Beam

Thursday, May 14, 2020

Don't name ANYTHING AUX, or NUL, or...

Further to my earlier post, I discovered 'aux' is not just a bad choice for folder names, it's bad for ANY file name on Windows!

Apparently back in the Dark Ages (1974 or so) when Bill Gates invented computers, the Interwebs and everything else digital, AUX, NUL, COM3, etc. were deemed names reserved for the OS, "magical files" if you will. That decision lives on through backward-compatibility (c'mon, 1974?! CP/M?! DOS?!?!?).

While working on my project, MS Visual Studio Code happily agreed to let me name a file"aux.yaml". Even though this ominous warning appeared, it let me continue once I appended "yaml" to the name:

 Everything went fine until I tried to add the file to the project's working copy in Subversion. For some reason, no matter how many times I pressed "Add..." in TortoiseSVN, the file refused to appear in the commit list, and failed to adopt its stroppy little blue plus sign in Windows Explorer.

Hmm, let's open it with Notepad++ to make sure the file is OK - nope, Notepad++ complained bitterly about the file when I tried to open it:

So at this point I figure the file was somehow corrupted by my attempts to add it or move it around in the Subversion working copy, let's just nuke it and start over:

OK this is definitely weird.

A few minutes googling produced the answer: open an admin command prompt and delete or rename the file. The command ren \\.\C:\path\to\file\aux.yaml auxiliary.yaml put everything right again - TortoiseSVN happily added the file, Notepad++ opened it with nary a whimper, and Visual Studio Code - well, let's just say it has it's own opinion on file names.


How a 1974 bug still bites Win10 and Azure users