Symptom: OAuth login succeeded on the work box but cmd_status emitted three 'jq: error: Could not open file' lines and showed empty fields. Same pattern would have hit every subsequent chat turn via larry.sh's MESSAGES_FILE reads. Root cause: install-larry.sh fetches a Windows-native jq.exe on cygwin/ mobaxterm platforms. Windows jq can't resolve Cygwin paths like /home/mobaxterm/.larry/.oauth.json when they come in as argv arguments (it interprets the leading slash as a Windows root). Bash's `>` redirection worked because bash itself does the path open and hands jq an fd — the read-side calls were passing the path string directly. Fix: every read-side jq call now uses stdin redirection (`jq '...' < file`), where bash does the open. Universal: - Linux/macOS native jq: identical behavior (was already file-open-from-bash) - MobaXterm/Cygwin/Git Bash with Windows jq.exe: now works - WSL: works (Linux-native jq, same as Linux) - Native PowerShell/cmd: doesn't apply — larry-anywhere is a bash script Changes: - lib/oauth.sh: new jqf() helper; 10 sites converted. Refactored cmd_refresh to drop --slurpfile (which can only take a path) — pre-reads the previous refresh_token, then uses --arg. - larry.sh: add_user_text / add_assistant_blocks / add_user_tool_results now pipe $MESSAGES_FILE via stdin too. Verified: cmd_status against a real token file produces clean output, no jq errors. Syntax check passes both files. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2 lines
6 B
Plaintext
2 lines
6 B
Plaintext
0.5.4
|