For quite a while, I've been using the vim-ps1 plugin for Powershell syntax highlighting.  It's generally fine, but I have one annoyance with it: When I open a Powershell file, the plugin opens a horizontal split with a Powershell terminal in it.  That's...fine, but most of the time I don't want that.  And the documentation doesn't say anything about it.

Well, fortunately there's a resolved Github issue with the answer.  Turns out the issue isn't actually with vim-ps1, it's with coc-powershell, which actually does mention this issue in the docs.  Why the language server is popping up a terminal window isn't clear to me, but the solution is to add this to your coc-settings.json file:
"powershell.integratedConsole.showOnStartup": false

Easy fix!  Unfortunately, I can't check that into my vim-config Git repo because I have my Intelephense license key in that file, so I need to document it someplace else.  Hence this post.

As an aside, before scouring the web for that answer, I tried asking Claude.  That didn't go well.  It's first answer was to "look at your Vim config" or try disabling plugins, which was not even remotely useful.  When I pointed that I knew there was a setting for this, it asked me where I saw it.  If I remembered that, I wouldn't need to ask the AI!  At that point, I decided it was easier to do this the old-fashioned way and ended up checking the Github issues and found the solution in a couple of minutes.

Things like that make me appreciate William Bernstein's comments in his interview with Rob Berger.  When asked about using AI in his writing and research, he said that AI is extremely useful, but it's kind of like having a very dumb graduate assistant.  That seems about right to me.  Even a dumb grad student is still smart enough to get into grad school, so they're capable of doing some very helpful work, but they still have some significant limitations.

The codebase itself is built on Node JS, but I have to run it in WSL.  There are various build issues that keep it from building cleanly in Windows and it would be a bit of work to fix that.  But it builds just fine under WSL, so it's easier to use that.

The dev setup uses a Docker container running HAProxy.  It's set up to proxy the static portion of the website to the shared dev server (which is on the VPN) and direct the traffic for the dynamic part to a local port.  So we have a HAProxy running in Docker, the local dev server running in WSL, and the browser running in Windows.

The problem: In the default WSL config, this doesn't work.  The proxy to the shared server works just fine.  So if I go to wwwlocal.site.com, that works as a proxy to wwwdev.site.com.  Perfect!  However, wwwlocal.site.com/login is supposed to proxy to localhost:4321, but that results in a 503 error.  However, I can go directly to localhost:4321 and it works just fine, so this is clearly a networking issue.

The solution was to just add a few lines to my $home\.wslconfig file on Windows.  The following lines did the trick:

[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true

You can read more about these settings here.

Today I finally got around to making SSH agent work in Powershell with Git.  For the last year or so, I haven't had to deal with because my work mostly involved writing PHP code inside of WSL.  In that scenario, you're essentially using Linux, so ssh-agent works just fine.

But on native Windows with Powershell...not so much.

I mean, sure, I could just use Git BASH.  But why would I want to do that?  Powershell is awesome, and even if I probably know BASH better, I prefer Powershell.

But it turns out it wasn't all that difficult to get things working in Powershell.  There were two pieces to it:

1. Use the right SSH agent (i.e. the one that comes with Git).
2. Write a Powershell adapter for it.

It turns out that there's a Windows service for "OpenSSH Authentication Agent".  I'm not entirely sure what installs that, but apparently it's different from the ssh-agent that's installed with the Windows Git package and the ssh-add command from that doesn't seem to talk to it properly.

My solution was to just disable that service and use the plain-old ssh-agent that comes with Git.  The only problem with that is that the traditional invocation of eval `ssh-agent` doesn't work in Powershell because it outputs a BASH-formatted script.  But that's easily fixed with a couple of regular expressions.  So I added this to my Powershell $profile:

Set-Alias ssh-agent "$env:ProgramFiles\git\usr\bin\ssh-agent.exe"
Set-Alias ssh-add "$env:ProgramFiles\git\usr\bin\ssh-add.exe"

# Need to turn off Open SSH Authentication Agent system service,
# then run the ssh-agent from Git.
function Start-SshAgent {
    $output = (ssh-agent)
    $sock_match = ($output | Select-String -Pattern 'SSH_AUTH_SOCK=(\S+);')
    $sock_path = $sock_match[0].Matches.Groups[1].Value
    $pid_match = ($output | Select-String -Pattern 'SSH_AGENT_PID=(\d+);')
    $agent_pid = $pid_match[0].Matches.Groups[1].Value
    $env:SSH_AUTH_SOCK = $sock_path
    $env:SSH_AGENT_PID = $agent_pid
    Write-Output "Agent pid $agent_pid"
}

Start-SshAgent

And there we go!  Now I can just run ssh-add to add my key and Git picks it up as expected.

I see this all the time on my Windows 10 work laptop, where I use WSL extensively.  It usually happens after my laptop has gone to sleep.  I come back in the morning, log in, and all of my open WSL gVim windows are just gone.  The processes are still running, they're just not displayed and they're MIA from the Windows taskbar.

Fortunately, this is easily fixed by just starting a new WSL GUI app.  So I generally just pop up my Windows Terminal and start a new gVim instance, and then the running instances pop back into existence and they're fine until the system sleeps again.

I have no idea why that happens, nor if it's specific to Windows 10 or anything else.  It's just one of those things that's annoying but not a big deal.  Rant over.

I saw this the other day.  At some point, something got updated and when I tried to open a new WSL terminal, it would always fail with the message Error code: Wsl/Service/0x80040326.  Oddly enough, the WSL shells and processes I already had running still worked, I just couldn't start any new ones.

Luckily, the fix is pretty simple.  You just have to open up a Powershell instance run wsl --update to update WSL and then wsl --shutdown to reboot it.  That's it.  It's just annoying because that's a manual process - you still need to manually run the update, even if you reboot your computer.

Anyway, I noticed a rather annoying issue where Nextcloud was leaving hundreds of stale auth tokens in the database.  Apparently, I'm not the only person this has happened to.

While Nextcloud has a menu item to revoke and remove stale sessions on their settings page, it's on a per-item basis.  So if you have hundreds of stale sessions, the only way to remove them is to go through, one by one, and click the menu and select the "revoke" option.  Needless to say, this is terrible.

The less annoying solution is to just go straight into the database and delete them there.  You can just run something like:
DELETE FROM oc_authtoken WHERE last_activity < <whatever_timestamp>;
That might be ugly, but at least it doesn't take forever.

It's important to note that, in addition to being annoying, this is evidently also a performance problem.  From what I've read, it's the reason that authenticating to my Nextcloud instance had gotten absurdly slow.  The app responded fine once I was logged in, but the login process itself took forever.  It also seems to be the reason why my hosting provider's control panel has been showing I'm way over my allotted MySQL execution time.  After deleting all those stale sessions, not only is login nice and snappy again, but my MySQL usage dropped off a ledge.  Just look at this graph:

As you can see, January is a sea of red, and then it drops off to be comfortably under the limit after I deleted the old sessions.  The Nextcloud team really needs to fix this issue.

At work, we have a PHP project that has automated integration tests written in Python.  The top-level directory of the Git repo is the normal PHP stuff, but the tests/integration/ directory is a Python sub-project that uses Poetry and Pytest.

Now, I use Vim as my editor and CoC with Intelliphense and Pyright for my PHp and Pythong language servers.  Since the main repo is PHP, Intelliphense works just fine.  Hwoever, Pyright needs a little help.  In particular, it didn't find the third-party dependencies or the integration test framework packages because it didn't know where to look.

Fortunately, this is easily fixed by creating a pyrightconfig.json file.  I was able to create one of those in the top-level directory of the project and add an "execution environment" to tell Pyright where to find the root of the Python project.  I set it to the "tests" directory because, while the main dir is tests/integration/,  that directory is also a Python module, so using "tests" lets Pyright find the "integration" module.

My particular file looks like this:

{
    "venvPath": "tests/integration",
    "venv": ".venv",
    "executionEnvironments": [
        {
            "root": "tests
        }
    ]
}

I'm not entirely sure why.  But it's a pain in the butt.

This has come up a couple of times in working on one of our projects for work.  This particular one is an internal command-line application written in PHP and using the command-line components from the Symfony framework.  I won't get into the details, but the point is that it glues together the various steps required to configure and run certain things on Linux-based servers.  So to test it, I have to put the code on my test server and make sure it works there.

The problem that I ran into today was that I tried to add a new command class to the application and it barfed all over itself.  The Symfony DI container complained that it couldn't find a certain class name in a certain file. The PSR-4 autoloader requires that the class name and namespace match the filesystem path, so usually this indicates a typo in one of those.  But in this case, everything was fine.  The app worked fine on my laptop, and if I deleted the new command, it worked again.

Well, it turns out that running composer du -o fixed it.  I suspect, based on the composer documentation, that the issue was that the class map was being cached by the opcache.  The Symfony cache was empty, so that's about the only one left.  Unfortunately, this is pretty opaque when it comes to trouble-shooting.  I would have expected it to fall back to reading the filesystem, but apparently there's more to it than that.  Perhaps it's related to how Symfony collects the commands - I haven't put in the time to investigate it.

But in any case, that's something to look out for.  Gotta love those weird errors that give you absolutely no indication of the solution.

$ dpkg-reconfigure gdm3
$ systemctl restart display-manager.service

The reconfigure will bring up a menu that allows you to choose from the installed display managers.  There's a nice summary with pictures here.

If anyone cares, the context here is that I run Ubuntu 20.04 with the Trinity Desktop Environment on my home destkop/server.  The problem is that pretty much every time I run an upgrade on that box it resets the display manager from TDM back to the default GDM. 

This is actually a really big problem because GDM doesn't work on this box.  Aside from the disk drives, most of the hardware in this box is about 10 years old.  So the video card is sufficiently archaic that GNOME just can't deal with.  When I try to log into GNOME or even just use GDM, I end up with massive display corruption and the desktop is basically unusable.  

One of these days, I should really replace that computer.  Or maybe rebuild it.  Or possibly just relegate it to purely headless server duty and get a different box to use as a desktop.  One day....

This week my wife wanted a USB thumb drive so she could take some documents to her mother's house and print them out using her printer, because ours is a pain in the neck and it's out of ink.  Well, the good news is that I had two drives handy!  The bad news is that neither of them did anything when I plugged them into her computer.

Of course, it turns out that, at some point, I'd used both of these as bootable drives for a something Linux-based.  This means, of course, that Windows can't read the partitions, so it can't write files to them.  In fact, when I plugged the drives in, nothing happened - they didn't even show up in Explorer.  So I had to fix them.

Well, the first one was pretty easy.  I just used the "Disk Management" console (a.k.a. diskmgmt.msc).  Using that, I was able to see the disk and it's partitions.  It was then a simple matter of deleting the existing partitions, creating a new one, and formatting it.  Then Windows found the drive just fine.

That didn't work so well for the second disk.  The drive showed up with an EFI partition and a lot of unallocated space.  I tried to create a partition in that space, but it didn't work.  So I eventually ended up downloading Rufus.  This is a handy tool that I've used in the past to image USB drives with ISO images.  Well, it can also do a plain-old reformat of a drive.  I just selected "unbootable" for the boot image, GPT for the partition type, and told it to format.  Rufus successfully blew away the entire drive and gave me back a fresh, working USB drive.

So the process wasn't too bad.  It's just a matter of realizing what's going on and getting an appropriate tool to fix it.