What happened
Running scout.py with piped/non-interactive stdin (e.g. echo "4" | python scout.py, or any stdin that hits EOF before the CLI expects it) does not exit. Instead it prints:
```
Error: EOF when reading a line
```
and redraws the platform menu, then immediately tries to read input again, hits EOF again, and repeats. This loops forever and has to be killed externally (SIGKILL) rather than exiting.
Repro
```bash
printf "4\ntorvalds\n\n" | python scout.py
```
Expected: either the intended inputs get consumed and the GitHub scrape runs, or the tool exits cleanly once stdin is exhausted.
Actual: infinite reprint of the menu with repeated EOF when reading a line errors, no exit, process has to be killed.
Why it matters
Anyone trying to script/automate Scout (which is a reasonable thing to want for a lead-gen CLI, e.g. driving it from another script or CI) hits this immediately. Right now the only safe way to use it is fully interactive at a real TTY.
Suggested fix
Catch EOFError at the top-level input loop (wherever input() is called for the menu prompt) and exit gracefully with a message like No more input, exiting. instead of looping. Happy to open a PR for this if useful.
What happened
Running
scout.pywith piped/non-interactive stdin (e.g.echo "4" | python scout.py, or any stdin that hits EOF before the CLI expects it) does not exit. Instead it prints:```
Error: EOF when reading a line
```
and redraws the platform menu, then immediately tries to read input again, hits EOF again, and repeats. This loops forever and has to be killed externally (SIGKILL) rather than exiting.
Repro
```bash
printf "4\ntorvalds\n\n" | python scout.py
```
Expected: either the intended inputs get consumed and the GitHub scrape runs, or the tool exits cleanly once stdin is exhausted.
Actual: infinite reprint of the menu with repeated
EOF when reading a lineerrors, no exit, process has to be killed.Why it matters
Anyone trying to script/automate Scout (which is a reasonable thing to want for a lead-gen CLI, e.g. driving it from another script or CI) hits this immediately. Right now the only safe way to use it is fully interactive at a real TTY.
Suggested fix
Catch
EOFErrorat the top-level input loop (whereverinput()is called for the menu prompt) and exit gracefully with a message likeNo more input, exiting.instead of looping. Happy to open a PR for this if useful.