command_help VS pinpoint

I use a lot of CLI tools, but haven't written many for myself. Mostly, aliases/functions and some scripts in Bash/Python.

Extract details for command options from man/help: https://github.com/learnbyexample/command_help/blob/master/c...

cut-like syntax for field manipulations with regexp, negative indexing, etc: https://github.com/learnbyexample/regexp-cut/blob/main/rcut

simple calculator using python syntax: https://learnbyexample.github.io/practice_python_projects/ca...

I wrote a Linux CLI tool [0] that parses the man/help pages to extract option details. Works most of the time for me, but there are plenty of corner cases that don't work.

[0] https://github.com/learnbyexample/command_help

https://github.com/learnbyexample/command_help to extract help text from builtin commands and man pages, ex:

https://github.com/learnbyexample/command_help is big enough to warrant a repo, examples, limitations, etc. I had a list of todo items to improve the script, but after years of usage, I'm fine with the limitations since I rarely encounter them. This helps me to extract documentation of particular options, here's an example:

I wrote one a few years back (https://github.com/learnbyexample/command_help). It has a few corner case issues, but works most of the time for me and supports multiple options to be retrieved.

I particularly wanted to lookup documentation for command options from my terminal (instead of the website), so wrote a script for it: https://github.com/learnbyexample/command_help ... Have a long pending todo list, but despite the issues, the tool is good enough for my needs.

When I start a project, I usually try to write the programs incrementally. Say I need to iterate over files from a directory. I will make sure that portion is working (usually with print() statements), then add another feature — say file reading and test that and so on. This reduces the burden of testing a large program at once at the end. And depending upon the nature of the program, I'll add a few sanity tests at the end. For example, for my command_help project, I copy pasted a few test runs of the program with different options and arguments into a separate file and wrote a program to perform these tests programmatically whenever the source code is modified.

Agreed! I've found that staying in my workflow leads to fewer inadvertent context switches (like ChatGPT in-browser -> HN -> ... -> rabbit hole). MacGPT looks great. I created a similar plugin for my Windows keystroke launcher for the same reason. If anyone's interested, you can check it out here: https://github.com/dkgv/pinpoint

I shared the exact same sentiment when I transitioned to Windows after a long period of only using macOS. I eventually began building a launcher myself using C# and over time it has become my daily driver. Feel free to check it out at https://github.com/dkgv/pinpoint, PRs welcome :-)

A few other nice candidates I found include:

- Keypirinha: https://keypirinha.com/

- Wox: https://github.com/Wox-launcher/Wox

- ueli: https://github.com/oliverschwendener/ueli

Don't have a video unfortunately, but you can download it from here: https://github.com/dkgv/pinpoint/releases (pick the stand-alone release unless you have .NET 5 installed already)

As the title states we made a keystroke launcher for Windows, sort of an Alfred alternative. It is definitely still a work in progress, but we do have quite a few features at this point such as controlling Spotify, searching the web via DuckDuckGo bangs and a lot more. A full list of features and a download link is available at our repo at https://github.com/dkgv/pinpoint. If you're interested in trying it out or even contributing, please check it out :)