A Notification When Any Long Command Finishes

Three domed indicators are mounted vertically on the black body of Status Light. They can mirror a long command's outcome if a separate, verified adapter exists, while a shell wrapper supplies the dependable completion event.

What are the shell-level ways to detect completion?

An explicit wrapper is easiest to reason about: record the start, run one command, capture its result, notify and return that same result. An alias can cover a fixed command, while interactive-shell pre-command and post-command hooks can observe a wider set of commands.

Hook names and behavior differ across shells. Read the documentation for the installed shell and avoid copying a callback intended for another one. Explicit wrappers are usually safer for production commands because their scope is visible.

How do you avoid alerting on every trivial command?

Measure elapsed monotonic time and notify only after a chosen local threshold. Maintain a small deny list for interactive commands that manage their own interface, and suppress alerts when the shell is not attached to an interactive user. The threshold belongs in configuration, not scattered aliases.

Do not infer duration from command history timestamps after the fact. Save start state before execution and clear it reliably after the post-command handler runs.

How do you carry exit status into the notification?

Capture the status before running any formatting, logging or network command, since each of those has its own result. Pass the saved value to the notifier, then return it from the wrapper. A notification transport error should be logged separately and must not overwrite the command's failure.

Signals and process termination are more complex than ordinary success or failure. Treat interruption, missing status and wrapper errors as unknown unless the specific command provides a documented interpretation.

How do you push the signal off the screen?

Write a small local state record and let an independent worker produce a bell, desktop message or verified hardware command. This keeps a slow light or network service from delaying the shell prompt. Include command label, result and finish time, but do not store secrets from the command line.

The Status Light has an appropriate three-lens display, not a confirmed programmable connection. Prove the shell logic with a text file first, then test concurrent terminals, cancelled commands and a failed notifier before adding physical output. Limit any captured command label to a safe static name. Full shell command lines may contain tokens, URLs or customer data that do not belong in logs or external notifications. Run the notifier without elevated privileges and make concurrent shells write separate records. After a restart, discard incomplete observations rather than inventing outcomes.