Skip to main content

Scripting with GO: what about Windows?

!!! Warning !!!

Once again, let me repeat, I'm by no means a developer nor a sysadmin (at least no more since 5 years).
This means that, while the solution below worked for me and I could reproduce it, it's not 100% safe neither!
Also, my solution still feels incomplete (read further), so if someone know the tweak to make it even more compete, please share it and reach out in Twitter, I'll be waiting.

Introduction

By now, everyone following @jessfraz read her take about the very neat "little hack" from @cloudflareUsing Go as a scripting language in Linux

As a good WSL Corsair, I tried it and it just worked!
But then, based on my latest playground of having a seamless coding experience between WSL and Windows (thanks @bketelsen for the love and notification spam), I really thought it would be unfair to "my Windows side" to not be able enjoying the fun of GO scripting (yes, split personality is bad).

So as the good Corsair I am, it was time to see if some shinny loot was waiting to be found.

Understanding Windows extensions

And, oh boy, there was this nice chest waiting to be open. Welcome to the Windows Registry treasure island!

I knew what I was searching for, make a specific extension act as a script (./<filename.ext>), and then I came across something similar.
The vision was becoming clearer and further research brought me to this Microsoft doc.

To be totally sincere, I didn't understood it all, but then an idea came: there is already a "script" file type that I could base myself from.
Thank You Powershell!

Imitation is the purest form of flattery

Before I do any change, let's see the behavior when trying to run a "go script":

As I have VSCode installed, the fact that I launch a ".go" file it will open it.

So the next logic step was to "break" this relationship and make the ".go" file executable.
For that, after looking at the ".ps1" and the Microsoft article as a reference, I decided to give it a GO (yes, bad pun sorry).

Here are the steps to make the change in the Registry:
  1. Open the registry (duh)
  2. Go to: Computer\HKEY_CLASSES_ROOT\.go
    • Change the value of "(Default)" to: "go"
    • Add a new String value name "Content Type" with the value: "text/plain"
  3.  Go to: Computer\HKEY_CLASSES_ROOT\.go\OpenWithProgids
    • Delete any additional key other than "(Default)"
    • Ensure "(Default)" has no value
  4. Create a new Key with the name "go": Computer\HKEY_CLASSES_ROOT\go
    • Change the value of "(Default)" to: "0"
  5. Create a new Key with the name "0": Computer\HKEY_CLASSES_ROOT\go\0
  6. Create a new Key with the name "Command": Computer\HKEY_CLASSES_ROOT\go\0\Command
    • Change the value of "(Default)" to: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" "go run '%1' %*"
And, well that's it ... 
Let's open a new Powershell console and try to run again the "go script" from before:

Feeling of imcompleteness

Right now, what I feel is really missing is to have the script displaying in the same Console window.
So if anyone know what should be changed to achieve this, please share it.

Conclusion

From my (hobbyist) point of view, this solution is almost cleaner as we call directly the "go" program instead of "gorun" for the Linux solution.
More importantly, and now I'm talking to you Brian: this also means that we could (eventually) call a versionable go application ... but this one I'll wait on your blog post.

Hope you will have as much fun as I did with this "go scripting"!



>>> Nunix Out <<<

Comments

Post a Comment

Popular posts from this blog

WSL: One Home to host them all

Introduction This blog post will explain how a single home mount can be shared accross all  the WSL instances. It was quite fun to find the idea and then make it happen. It will use all the tools currently available from WSL, so please don't expect a "Linux only" as Interopability will be heavily used. And before I start, here is my point of view about WSL: It's not only  Linux! It's different, just like GNU is different from Unix (yes I said it). We have finally the strength of both worlds combined. And while I do understand the "dev" aspect is meant to be reproducible in a Linux prod environment, the "ops" side is meant to take advantages of everything that can make the full environment feeling Home. Setup requirements In order to really enjoy this solution, I do recommend having 2 or more WSL distros installed or, if you fell like a real WSLCorsair, try @bketelsen crazy setup (I love it)! While the distros are downlo

Docker + WSL: Get 2 daemon for the price of 1

Introduction almost two years ago, Docker announced the capability of switching between the Linux and Windows containers "mode" (far from the right click that we have today). At that time, I wrote a blog post on how to run both daemons at the same time ( http://darthnunix.blogspot.ch/2016/10/docker-for-windows-2-daemons-enter-in.html ) Fast forward to 2018, and while we were blogging on how to get the TLS connection from WSL docker client with  Rory McCune  ( https://raesene.github.io/blog/2018/03/29/WSL-And-Docker/ ), another blog post, by Stefan Stranger drew my attention (read: blew my mind) as I was trying to reproduce the same: how could I "bind" the docker socket in WSL with the Docker for Windows Linux mode socket ( https://blogs.technet.microsoft.com/stefan_stranger/2018/04/02/access-my-docker-for-windows-kubernetes-cluster-from-debian-wsl/ ) From 1 to 2 daemon: DemonHunter mode achieved Now that we have all the required setup resources, let's b

VSCode + WSL: the SSH way

The initial idea early 2017, Rich Turner made a demo where Visual Studio was used to develop C++ code, however the debugging environment targeted was WSL! With some magic, he showed something that he had forbidden from the initial release of WSL: writting directly to the WSL filesystem (still a big no-no actually). Of course, this triggered a lot of curiosity and the WSL Corsair had to loot from it too! SSH to save the day the biggest challenge was to find a way that not only could be easy to setup on both ends, and also would be approved  by the WSL team.  TLDR: if you use the Windows Path, You Die! #ThereBeDragons Another way, more Linux-oriented, needed to be used and hopefully a solution already existed and was simply waiting on being used: SSH🔐 The setup the setup is done in 2 distinct parts: Setup the SSH server on WSL Setup the SSH client on VSCode  While the SSH server is a standard procedure in Linux, finding the right  plugin for VSCode was a bit more chall