git-tidy VS command_help

We squash merge at my work, so I use git-tidy basically every day. It’s the only thing I’ve written in my 10+ years as a dev that I have ever regularly used.

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.