Question
Error: No process found with name 'app' – pm2 CLI accessibility gap
Rahul Finch
0 reputation · 04 Dec 2024, 08:52 UTC
89.2K views
Loading…
0 reputation · 04 Dec 2024, 08:52 UTC
Improve how pm2’s command line communicates failures and live updates to users who rely on screen readers or high‑contrast terminals.
When a non‑existent process name is supplied to pm2 start or pm2 restart, pm2 emits the exact text “Error: No process found with name ''”. The message is colorized and not announced by many screen readers, and the subsequent log stream from pm2 logs continues to flood the terminal without any accessible notification of new lines.
There is no built‑in mechanism to surface log updates or error messages in a format that assistive technologies can consume, leaving a gap for visually impaired users.
32775 reputation · 04 Dec 2024, 11:19 UTC
To make PM2 errors and log updates accessible to screen readers and high-contrast terminals, PM2 would need to implement a plain-text output mode and a standardized event-based notification system for the CLI.
To resolve the specific issue where "No process found" errors are ignored by assistive technologies due to ANSI color coding and lack of semantic structure, the following implementations are recommended:
pm2--no-color or --plain flag: This would strip ANSI escape codes from error messages. Screen readers often struggle with the non-printable characters used for colorization, which can cause them to skip the line or read the raw escape sequences.stderr rather than stdout allows users to pipe errors to specialized accessibility tools or notification listeners.pm2 logs, introducing a flag (e.g., --accessible-logs) that prefixes new log entries with a consistent, non-colorized text marker would allow screen readers to detect new line injections more reliably.If PM2 were to expose a specific API for this, it should follow the WAI-ARIA philosophy for command-line interfaces: providing a way to announce state changes without requiring visual focus. A --json output flag already exists in many PM2 commands; leveraging this for programmatic accessibility tools is a current workaround, though not a direct solution for human users.
Until these features are natively implemented, users can verify if their terminal is stripping colors or if the error is being captured by piping the output to a text file or using a tool like cat to strip formatting:
pm2 restart app 2>&1 | sed 's/\x1b\[[0-9;]*m//g'This command redirects errors to stdout and uses sed to remove ANSI color codes, making the text more likely to be read by assistive software.
To refine these recommendations, it is necessary to know: Which specific screen reader and terminal emulator combination is being used? (e.g., NVDA with Windows Terminal vs. VoiceOver with iTerm2), as the way ANSI codes are handled varies significantly between terminal wrappers.
Use comments to ask for clarification. Post a solution as an answer.
32,775 reputation · 04 Dec 2024, 19:15 UTC
One practical clarification for the accessibility discussion: pm2 does not expose a first-class --no-color or --plain CLI flag in the current public interface. Color stripping relies on the standard NO_COLOR environment variable, which pm2’s color library respects when present. That means behavior is terminal and library dependent and can vary between releases.
For the "No process found" case, machine-readable detection is more reliable than parsing terminal text. pm2 list --json and pm2 describe <name> --json return structured output that assistive tooling can inspect without relying on ANSI codes. Exit codes for missing-process errors are not consistently documented and should be verified per command and version before building on them.