AutoHotKey finally fell off my list, to be replaced by... powershell. After about 8 years of utter disdain for the mistake that is powershell, I’m actually enjoying giving it a proper test drive.
I can’t quite believe it myself but i chsh’d to pwsh on my mac and linux boxes too.
Goodbye 30 lines of AHK just to capture and parse the output of a RunWait (in practice it was better to create a WSH com object and exec the command from there since it’s only 3 lines of code to grab stdout then).
The AutoHotKey programming language is quirky and weird, even when compared to Powershell's quirkiness, but there are classes of things that AutoHotKey can do that I don't know how you would do on Powershell:
prepend or append selected text to what's already on the clipboard with Ctrl+[ or Ctrl+]
find all windows with specific text in the title and resize them in a custom way (Window+])
insert custom strings or large blocks of text in other programs triggered by a keypress (its original reason for being)
eg: ]s inserts the current date and time: 2020-12-25 11:57:07
define a keypress to start Putty with a given profile, enter logon credentials, CD to a folder and start Midnight Commander
(these are my own keypress definitions)
I once wrote an AHK script to start VLC streaming a local radio station at a specific time, then start Audacity to record audio, then stop the recording and streaming at the end of the program and save the audio as WAV and MP3. This let me go for a bike ride in the late afternoon before dark, then come home and listen to my favorite radio show later in the evening. It's not necessary anymore, but back in 2008 this was an amazing thing to put together.
This was a good list, just for fun i had a bash at #1 (an excuse to learn as much as anything...):
prepend-selection.ps1:
$before = Get-Clipboard
[void][System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms')
[System.Windows.Forms.SendKeys]::SendWait("%({TAB})") # when launched, a powershell.exe opens and steals focus, this alt+tab takes focus back to the app that has the text selection
[System.Windows.Forms.SendKeys]::SendWait("^(c)") # ctrl+c
$after = Get-Clipboard
Set-Clipboard -Value ($after + $before)
Now for the impossible bit - perform this action on ctrl+[ keypress... I created a new shortcut on the desktop (in the start menu would also work) with a target of:
And the "start in" was set to the dir containing prepend-selection.ps1
Lastly the "shortcut key" of the shortcut was set to CTRL+SHIFT+[ -- i couldn't use CTRL+[
... and it works. Open an app like notepad, put something on the clipboard, select some other text then ctrl+shift+[ with notepad still having the focus and... wait far too long but then eventually powershell.exe opens and i have the selected value prepended to my clipboard.
0 out of 10. Would not do again, AHK definitely beats powershell for this use case :-)
For #2 i know how to do that already - create a Shell.Application com object and then cycle through the window list and set width / height / top / left to suit.
For #3 i didn't try it but i wonder if there's a mechanism where i can insert a function to be called back into window's message processing loop. Like how i imagine AHK does it. This is just a thought, i'd just use AHK before i actually tried this.
For #4 this suffers the same issue as #1 with the "define a keypress" limitation but otherwise it's just an exec + focus window + send keys (likely with some hacky sleeps in between).
The code you wrote will do but in AHK its 1 liner, ets 0 memory and CPU. You can also compile it into exe or use portable AHK. It can stay in tray with another line.
How did you finally get into it? I was stoked about it 15 years ago when I first read about it, but using it never clicked with me. Every now and then I enthusiastically try to embrace it, just to eventually be annoyed by all the clumsiness, lack of speed, or about having to wade through layers of objects just to get to the information I need. It just does not have the feeling of a tool for shell users honed by shell users, but a soulless navigation tool for a Byzantine object structure.
I finally decided Powershell is not so much a shell but rather an environment good for scripting.
What direction did you come from when embracing it? Did you have a strong background of Unix admin / developer use of shells?
It’s early days on my test drive. I don’t know how well it’ll fare for fairly common actions in bash like “here documents” or what the equiv of shopt extglob is in pwsh.
My usual cli usage is what i’d call “text manipulation” - slicing and dicing command output or converting csv-like data in some way or another.
My toolset is the usual suspects - bash, sed & awk but beyond a certain complexity i’ll switch to python.
The key thing for me is i can still use grep, sed, awk and python in pipelines as before but i’m attracted by the easy data access in pwsh.
The idea that Get-Process returns an object and i can just query each process’s WSS attribute for example is appealing right now (as opposed to explicitly manipulating text to suit, e.g. grep resident /proc/*/statm or ps -o rss or whatever approach)
AHK is not comparable to powershell. They overlap in some segments but generally, what AHK can do, you would have to reimplement in Posh and it would be slow as hell.
Aha! A folder full of .ps1’s (that were .ahk’s) begs to differ on this point :-)
Some random examples i use all the time:
* i have a bunch of apps (i think of it like a workspace) that i open for specific tasks - e.g. when playing ham radio i’ll open a tool that lets me duplicate traffic to/from a serial port (com0com) so that multiple apps can share 1 physical port, a tool that lets me control my radio (flrig), a tool that lets me route audio between devices and software without a mess of cables doing it in hardware (voicemeeter banana), a tool that encodes/decodes messages (wsjtx), a tool that shows what grid squares i’m hearing (gridtracker) and a tool for logging (home brew). They all need to be arranged in fairly bespoke ways across a couple of screens to let me work effectively - bind the shortcut to the .ps1 to a keyboard shortcut and i’m done.
The same idea exists for my other workspaces (dev work - there’s different flavours for this one by task, photo editing, researching, presenting, etc. Etc.)
Things like sending “PS1;” CAT control command to my radio (this turns it on) are actually less lines of code in .ps1 than .ahk. My .ps1’s are about 2/3 the size of the .ahk’s in practice.
Before .ahk i was using python2 with the win32 module, .ps1 is comparably expressive to python2 - which surprises me.
Other .ahk’s i use all the time are basically glorifed macros for common actions i perform. Again shorter to express in powershell.
> A folder full of .ps1’s (that were .ahk’s) begs to differ on this point
I have tones of ps1 and tones of ahk files in folders. But its not comparable. Main use case of AHK is GUI automation, which is precisely not something powershell handles nor it will ever be in its scope.
I can’t quite believe it myself but i chsh’d to pwsh on my mac and linux boxes too.
Goodbye 30 lines of AHK just to capture and parse the output of a RunWait (in practice it was better to create a WSH com object and exec the command from there since it’s only 3 lines of code to grab stdout then).