Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix setup-hermes.sh should guard interactive prompts in non-interactive environments [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#17579•Fetched 2026-04-30 06:46:34
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
zerowill111zerowill111
Participants
zerowill111zerowill111
Timeline (top)
labeled ×3cross-referenced ×1referenced ×1

setup-hermes.sh currently assumes interactive stdin for optional prompts. When run from CI, Dev Containers, cloud bootstrap scripts, or any non-interactive shell, the bare read -p prompts can return EOF under set -e and make setup exit with a failure status.

Root Cause

setup-hermes.sh currently assumes interactive stdin for optional prompts. When run from CI, Dev Containers, cloud bootstrap scripts, or any non-interactive shell, the bare read -p prompts can return EOF under set -e and make setup exit with a failure status.

Fix Action

Fixed

PR fix notes

PR #17582: fix(cli): guard setup-hermes prompts for non-interactive environments

Description (problem / solution / changelog)

What does this PR do?

This PR fixes setup-hermes.sh to avoid failing in non-interactive environments.

The script currently used read -p directly for interactive questions, which can hit EOF and abort under CI/container/non-interactive execution (set -e), even when the user requested a headless install flow. This patch adds a small helper to detect non-interactive stdin and safely skip prompts, preserving interactive behavior while preventing EOF crashes.

Related Issue

Fixes #17579

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 🔒 Security fix
  • 📝 Documentation update
  • ✅ Tests (adding or improving test coverage)
  • ♻️ Refactor (no behavior change)
  • 🎯 New skill (bundled or hub)

Changes Made

  • setup-hermes.sh
    • Added prompt_yes_no() helper to centralize prompt handling.
    • Replaced direct read -p usage in the two installer prompts with prompt_yes_no().
    • In non-interactive mode, prompts now return a safe default without calling read, preventing EOF-related exits.
  • tests/hermes_cli/test_setup_hermes_script.py
    • Added regression checks ensuring prompt_yes_no() exists and is used.
    • Added assertions that interactive read -p usages are no longer present for these prompts.

How to Test

  1. Shell syntax check:
    • bash -n setup-hermes.sh
  2. Run focused regression tests:
    • scripts/run_tests.sh tests/hermes_cli/test_setup_hermes_script.py
  3. Validate non-interactive safety manually:
    • ./setup-hermes.sh </dev/null
    • Ensure installer no longer fails on interactive prompts and exits cleanly through non-interactive path behavior.

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run pytest tests/ -q and all tests pass
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: <!-- e.g. Ubuntu 24.04, macOS 15.2, Windows 11 -->
  • N/A

Documentation & Housekeeping

  • I've updated relevant documentation (README, docs/, docstrings) — or N/A
  • I've updated cli-config.yaml.example if I added/changed config keys — or N/A
  • I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
  • I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
  • I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

  • scripts/run_tests.sh tests/hermes_cli/test_setup_hermes_script.py (pass)

Changed files

  • setup-hermes.sh (modified, +42/-6)
  • tests/hermes_cli/test_setup_hermes_script.py (modified, +13/-0)
RAW_BUFFERClick to expand / collapse

Summary

setup-hermes.sh currently assumes interactive stdin for optional prompts. When run from CI, Dev Containers, cloud bootstrap scripts, or any non-interactive shell, the bare read -p prompts can return EOF under set -e and make setup exit with a failure status.

Evidence

In setup-hermes.sh:

  • The script starts with set -e.
  • The optional ripgrep prompt uses read -p "Install ripgrep for faster search? [Y/n] " -n 1 -r.
  • The final setup prompt uses read -p "Would you like to run the setup wizard now? [Y/n] " -n 1 -r.

The main installer (scripts/install.sh) already has defensive handling for this case via interactive checks and /dev/tty probing, so this would make the developer setup path consistent.

Expected behavior

If no interactive terminal is available, the script should skip optional prompts and print the manual follow-up command, for example Run 'hermes setup' after install.

Suggested fix

Port the prompt helper from scripts/install.sh, or guard both prompt sites with a TTY check. Reads should also be non-fatal, e.g. read ... || REPLY="n".

extent analysis

TL;DR

The setup-hermes.sh script should be modified to handle non-interactive shells by skipping optional prompts and printing manual follow-up commands when no interactive terminal is available.

Guidance

  • Check if a TTY is available before using read -p prompts, and skip them if not.
  • Port the prompt helper from scripts/install.sh to setup-hermes.sh for consistency.
  • Make reads non-fatal by using read ... || REPLY="n" to prevent script exit on EOF.
  • Verify the fix by running setup-hermes.sh in a non-interactive shell and checking that it skips prompts and prints the expected manual follow-up command.

Example

if [ -t 0 ]; then
  read -p "Install ripgrep for faster search? [Y/n] " -n 1 -r
else
  echo "Run 'hermes setup' after install."
fi

Notes

This fix assumes that the setup-hermes.sh script is the only place where interactive prompts need to be handled. If other scripts also use read -p prompts, they may need to be modified as well.

Recommendation

Apply workaround: Modify setup-hermes.sh to handle non-interactive shells by skipping optional prompts and printing manual follow-up commands. This will ensure consistent behavior with the main installer (scripts/install.sh) and prevent script exit on EOF.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If no interactive terminal is available, the script should skip optional prompts and print the manual follow-up command, for example Run 'hermes setup' after install.

#prompt formatting#chain error#conversation history#tool integration#LLM response

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix setup-hermes.sh should guard interactive prompts in non-interactive environments [1 pull requests, 1 participants]