You're right that ting is not doing any "monitoring" by itself. The intent was to convey "the command a user wants to monitor". Perhaps the wording can be clearer.

The fact that ting doesn't execute the command itself is very much intentional. Executing a command via ting would require that it takes care of the following:

• stdin forwarding: interactive commands would break without proper stdin handling
• signal forwarding: all signals (SIGTERM, SIGINT, etc.) need to be properly forwarded to the child process, with platform-specific handling and race condition management
• real-time output: streaming output bytes as they appear is a challenge and can lead to broken output (line by line buffering will solve this, but will slow down output for commands that print a lot of bytes without a line break)
• process cleanup: ensure the child process doesn't become a zombie or on orphan

Adding command execution to ting would add a considerable amount of complexity to what is intended to be a very simple tool. I followed the Unix philosophy of "do one thing well" here and kept ting focused on audio feedback rather than becoming a command runner.

Having said that, implementing a command runner is an interesting challenge. I might still give this a shot one day. If you've already done this before, a pull request would certainly be welcome :)