(Edit: https://en.wikipedia.org/wiki/Performance_Monitor in case people are unaware, usually known as... perfmon)
For example I have a `monitor` script in my dotfiles at https://github.com/nickjj/dotfiles/blob/master/.local/bin/mo... which for now just splits btop and a dedicated GPU monitoring tool.
If I'm already in tmux and run that script it splits a few tools in a new tmux window but if I'm not in tmux already then it creates a new "monitor" session with the same splits. I also have it assigned to my status bar where if I click Waybar's CPU icon, it "launches or focuses" that monitor script in a new terminal so it doesn't spawn duplicates if I click the CPU multiple times. Basically ultimate freedom in how I want to launch it.
What makes it different: Unlike static monitors like htop or btop, Perfmon is designed around a tabbed interface where each tab is just a shell command defined in a TOML config. If you have a specific script or a grep command you run every 5 seconds to check a log or a metric, you can just drop it into the config, and it becomes a tab in your dashboard.
Key Features: - Extensible: Define any shell command as a tab. - Live Metrics: Real-time sparklines for CPU, Mem, Load, and Network (works on Linux, macOS, and Windows). - Modern TUI: Built using the Go bubbletea framework for a clean, responsive feel. - Lightweight: Minimal resource footprint.
Bottom(btm) gives just more graphical than top.
TMUX supports adding static headers or footers to your terminal. You can put info / stats , whatever you want in a glance. It supports multiple panes or tabs with whatever you want as content. Session management. All from config files. But it also does so much more unrelated to your specific use case. It’s also been wrenched on for 2 decades. So it’s solid.
There’s also a lot of folks out that that hear perfmon and probably think of windows.
Yes, I realize now that the name "Perform" is taken. Will have it changed that resonates with the monitoring/observability theme.
Will fix other issues as well.
You should give a direct curl to an install.sh to provide a simpler installation step for you tool and besides I think it would be good to publish it on home brew for MacOS users.
This post came in a good moment because I am developing a CLI and I want to add some interactivity to it in the next major version and in some way your CLI has helped me with that.
This is my CLI (https://github.com/elC0mpa/aws-doctor)
There you can check how I implemented the home brew distribution and the install.sh file for the easy installation step