command_help VS notes

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.

I've documented some really cool things that vifm can do: https://github.com/sitaramc/notes/blob/master/vifm.mkd

So I wrote https://github.com/sitaramc/notes/blob/master/dac -- 30 lines of shell plus maybe another 30 or 40 of comments, and it does everything I want in a dotfile manager.

All this is painlessly taken care of by https://github.com/sitaramc/notes/blob/master/dac (documentation: https://github.com/sitaramc/notes/blob/master/dac.mkd)

If you have fzf installed, grab https://github.com/sitaramc/notes/blob/master/try, and run try dust. Then start typing -t jpg (for example). Then backspace over the jpg and change it to png. Or use some other options.

I hesitate to nominate any of them because (a) there are dozens or even hundreds of them and (b) I don't like any of them; I wrote my own because I needed a "hold" feature that no one had (i.e., when propagating changes to the repo, I want to hold back some parts of the change; https://github.com/sitaramc/notes/blob/master/dac.mkd explains better if you're interested

For those of you who are curious, https://github.com/sitaramc/notes/blob/master/vifm.mkd is my part "review" and part "tips and tricks" on vifm.

Most of my tools are in bash or perl, most of them less than 100 lines of code, (most of them are less than 200 even with comments). https://github.com/sitaramc/notes has all of them (terrible name for a repo full of tools I know; sorry!)

Absolutely vifm. My notes+tips/tricks on this at https://github.com/sitaramc/notes/blob/master/vifm.mkd

https://github.com/sitaramc/notes/blob/master/dac.mkd for documentation, https://github.com/sitaramc/notes/blob/master/dac.mkd for code, if you're interested.

if you're a vim user, you can't go wrong with vifm. My take on vifm is here: https://github.com/sitaramc/notes/blob/master/vifm.mkd -- can't hurt to give it a read (it's a wee bit outdated but not much; probably only the last section needs to be updated)