Dirtytrii Hermes Python Wrapper for Shell Cron
Purpose
Provide a safe workflow for diagnosing Hermes cron script= interpreter mismatches. The common failure modes are shell syntax being interpreted by Python, or Python code being interpreted by shell. The default workflow only diagnoses and proposes a wrapper plan; writing wrapper files requires user approval.
When to use
- A Hermes cron job fails with syntax errors around shell constructs such as strict mode, heredocs, or bash conditionals.
- A cron job fails with shell errors while the entry file contains Python code.
- The job's configured script extension does not match the interpreter used by the scheduler.
- A user wants a stable wrapper pattern for cron scripts while keeping the existing script path.
Safety rules
- Default workflow is read-only.
- Do not edit scripts, change permissions, trigger jobs, or update cron definitions without explicit approval.
- Do not copy production scripts into public documentation.
- Replace real paths with
<PROJECT_ROOT>,<SCRIPT_PATH>,<WRAPPER_PATH>, or<IMPLEMENTATION_SCRIPT>. - Do not expose script contents if they include credentials, private URLs, tokens, or production data.
Read-only workflow
- Identify the failing Hermes cron job and script path from metadata or user-provided error context.
- Read the error summary and classify the mismatch:
- shell syntax reported by Python means the entry is being executed as Python;
- Python syntax reported by shell means the entry is being executed as shell.
- Inspect cron metadata to determine how the scheduler invokes
script=for that job. - Inspect only the minimum safe lines of the entry script needed to identify its language and shebang.
- Compare the entry script language, extension, shebang, and scheduler invocation mode.
- Produce a wrapper plan using placeholders, without writing files.
- Include a verification plan that compares direct implementation execution with scheduler-style entry execution.
Evidence to collect
- Redacted job name or identifier.
- Configured script path as
<SCRIPT_PATH>. - Error class and first safe error line.
- Detected script language: shell, Python, or mixed.
- Scheduler invocation mode if known.
- Whether arguments need to be forwarded.
- Whether stdout/stderr and exit code must be preserved.
Stop conditions
- The script contains secrets or production-specific data that cannot be safely summarized.
- The scheduler invocation mode is unknown and cannot be inferred read-only.
- Fixing requires editing the script, chmod, cron update, or a manual job run without approval.
- The proposed wrapper might alter stdout/stderr or exit-code semantics.
Optional user-approved actions
Only after explicit user approval:
- Move implementation content to
<IMPLEMENTATION_SCRIPT>. - Replace the original entry with a wrapper appropriate for the real invocation mode.
- Set execute permissions.
- Run syntax checks and controlled dry-runs.
- Trigger or run the cron job once to verify recovery.
Generic wrapper patterns
Use these only as templates after approval.
Python entry that delegates to shell:
#!/usr/bin/env python3
import subprocess
import sys
SCRIPT = "<IMPLEMENTATION_SCRIPT>"
result = subprocess.run(["/usr/bin/env", "bash", SCRIPT] + sys.argv[1:])
raise SystemExit(result.returncode)
Shell entry that delegates to shell implementation:
#!/usr/bin/env bash
set -euo pipefail
SCRIPT="<IMPLEMENTATION_SCRIPT>"
exec /usr/bin/env bash "$SCRIPT" "$@"
Final report format
Summary: <interpreter mismatch diagnosis>
Job: <redacted job name/id>
Script: <SCRIPT_PATH>
Observed error: <safe summarized error>
Detected mismatch: <shell-as-python / python-as-shell / unknown>
Read-only evidence: <bullets>
Wrapper plan: <high-level plan with placeholders>
Verification plan: <syntax/direct/scheduler-style checks>
Needs approval before changes: yes