CLI tool for organizing your own scripts on linux

I have long hated managing my custom scripts. I plop them in a bin/ dir, then I forget what scripts I have, what arguments they take, and have to sometimes ls ~/bin/ or even nvim ~/bin/script to see what they do.

So I made a tool called clh (for 'Command Line Helper') that organizes all the scripts for me, plus has some handy features.

To execute a custom script, you do: clh group/script_name, but you can clh bin a script and then call it directly from anywhere.

Install from my Gitlab.

For an overview, here is the built-in help menu:

  clh group/script [args] ... group "self" may be omitted

    self - 
        alias - Assign an alias for a script/subscript.
        bin - Create symlink in `bin/` dir pointing to target script.
        edit - Create/Edit a script
        globalize - Convert a group into a global callable script
        help - Show help information
        move - Move a clh script from source to dest
        rm - Delete a script (CANNOT BE RECOVERED)
        source - Convert a script to be loaded via `source` instead of being executed

To get more info on a command, use clh help [group]/[subgroup].

Comments

[Baptiste Le Bouquin]

The forget-what-scripts-I-have problem is real — my ~/bin has drifted into a graveyard of one-off fix scripts where the filename is the only documentation. clh group/script plus a generated help menu is a much better contract than ls and hope.

Does clh edit enforce any structure on the script itself, or is the group/subscript layout purely the directory tree? The hardest part of this problem for me was never listing scripts — it was remembering arguments. A convention where a header comment block gets surfaced in clh help <group> would close that loop.

How does it handle scripts that need to run on other hosts? Most of mine only make sense on the box they were written on, but a few (cron wrappers, deployment helpers) need to travel, and symlink-in-bin vs. copying the whole clh tree changes how you'd sync them. Symlinks are clearly right for local ergonomics — but rsync-ing a tree of symlinks is its own little adventure.

Nice that source mode exists. Plenty of my "scripts" are really functions that need the caller's environment, and exec-ing them quietly breaks that.

[Reed]

group/subscript is purely directory tree. You can clh help group/subgroup to see your docblocks from your script. It's up to you to document your arguments. clh help group does show the first line of your docblock from your script, so you could document arguments there if you want. You could also edit the built-in scripts' docblocks with clh edit self/[script] if you want that (at that point, prob use a fork).

Wrt other hosts, I don't know. If you configure everything right and fully rsync, I'd think it'll work the same as local. But I haven't tried it.

Yeah! I have a cdf script (fuzzy cd) on my machine to get into my desired project directory. Like cdf ba clh gets me into ~/data/projects/bash/clh. This didn't work without both the source and alias features.