Scribbles for my bad memory

Date: September 2, 2025 Context: Investigation and resolution of test failures on Git Bash/Windows

Executive Summary

We encountered widespread test failures when running the eed test suite on Git Bash/Windows, while all tests passed on Linux. Through systematic investigation, we discovered multiple platform-specific issues with bats test framework and developed comprehensive solutions. This document captures the technical journey, root causes, and proven solutions for future reference.

The Problem

Initial Symptoms

• Multiple test failures on Git Bash: test_eed_logging.bats, test_eed_preview.bats, test_eed_single_param.bats, test_eed_stdin.bats
• All tests passed perfectly on Linux
• Mysterious file corruption in safety tests
• Pipeline-based tests consistently failing with "Command not found" errors

Example Failing Patterns

# This pattern consistently failed on Git Bash:
run bash -c "printf '1d\nw\nq\n' | $SCRIPT_UNDER_TEST --force test.txt -"

# Status: 127 (Command not found)
# Error: bash -c printf '1d\nw\nq\n' | /path/to/eed --force test.txt -

Root Cause Analysis

1. Missing Library Dependencies

Issue: eed_common.sh was using EED_REGEX_INPUT_MODE without sourcing eed_regex_patterns.sh

Symptoms:

• Logging tests failed because input mode detection returned empty regex
• Content that should be skipped was being logged

Fix:

# Added to eed_common.sh
source "$(dirname "${BASH_SOURCE[0]}")/eed_regex_patterns.sh"

2. Bats Pipeline Simulation Issues

Issue: Bats implements pipe simulation differently on Windows vs Linux

Technical Details:

• Linux: Native shell pipes or compatible simulation work correctly
• Windows/Git Bash: Bats' pipe parsing breaks complex pipeline commands
• Pattern run bash -c "command | other" becomes bash -c command | other
• The pipeline executes outside bats' control, losing exit code and output capture

Symptoms:

# What we wrote:
run bash -c "printf '1d\nw\nq\n' | $SCRIPT_UNDER_TEST --force test.txt -"

# What actually executed:
bash -c printf '1d\nw\nq\n' | /path/to/eed --force test.txt -
#           ^^^^^^^^^^^^^^^^^^ Only this part in bash -c
#                              ^^^^^^^^^^^^^^^^^^^^^^^^^ This runs outside bats

3. File System Stat Comparison Issues

Issue: stat output includes microsecond-precision access times that change on every file read

Technical Details:

• Tests compared full stat output including access times
• Reading files for verification changed access times
• Caused false failures in file integrity tests

Before:

original_stat="$(stat sample.txt)"
# ... test runs ...
[[ "$(stat sample.txt)" == "$original_stat" ]]  # Always fails due to access time

4. Regex Pattern Compatibility

Issue: Git Bash regex handling differences in substitute command detection

Technical Details:

• Fallback regex was too restrictive: s(.)[^\\]*\1.*\1([0-9gp]+)?$
• Pattern [^\\]* excluded characters needed for patterns like console\.log
• Made regex more permissive while maintaining safety

Solutions Implemented

Solution 1: Fix Library Dependencies

# In lib/eed_common.sh - added missing source
source "$(dirname "${BASH_SOURCE[0]}")/eed_regex_patterns.sh"

Solution 2: Cross-Platform Pipeline Patterns

A. Heredoc Approach (Recommended for Complex Input)

# Before (fails on Git Bash):
run bash -c "printf '1c\nchanged\n.\nw\nq\n' | $SCRIPT_UNDER_TEST --force test.txt -"

# After (works everywhere):
run "$SCRIPT_UNDER_TEST" --force test.txt - << 'EOF'
1c
changed
.
w
q
EOF

B. GPT's Pipeline-in-Bash-C Pattern (For When Pipes Are Needed)

# Before (fails on Git Bash):
run bash -c "echo '$script' | '$SCRIPT_UNDER_TEST' --force '$TEST_FILE' -"

# After (works everywhere):
run bash -c 'set -o pipefail; echo "$1" | "$2" --force "$3" -' \
    bash "$script" "$SCRIPT_UNDER_TEST" "$TEST_FILE"

Key Elements:

• Single quotes around entire bash -c content
• set -o pipefail for proper error propagation
• Pass variables as arguments ("$1", "$2") to avoid quoting hell
• Entire pipeline contained within one bash -c execution

Solution 3: Robust File Integrity Testing

# Before (fails due to access time changes):
original_stat="$(stat sample.txt)"
[[ "$(stat sample.txt)" == "$original_stat" ]]

# After (only check relevant attributes):
original_size="$(stat -c %s sample.txt)"
original_mtime="$(stat -c %Y sample.txt)"
original_inode="$(stat -c %i sample.txt)"

[[ "$(stat -c %s sample.txt)" == "$original_size" ]]     # Size unchanged
[[ "$(stat -c %Y sample.txt)" == "$original_mtime" ]]   # Modify time unchanged
[[ "$(stat -c %i sample.txt)" == "$original_inode" ]]   # Inode unchanged

Solution 4: Improved Regex Patterns

# Before (too restrictive):
fallback='s(.)[^\\]*\1.*\1([0-9gp]+)?$'

# After (handles escaped characters properly):
fallback='s([^[:space:]]).*\1.*\1([0-9gp]*)?$'

Testing and Validation

Proof-of-Concept Tests

We created tests/test_printf_pipeline.bats to validate our understanding:

1. Direct printf pipelines work perfectly (bypassing bats)
2. GPT's approach works reliably (pipeline within bash -c)
3. Problematic patterns consistently fail (pipeline across bash -c boundary)

Results

• Before: Multiple test failures, warnings, file corruption fears
• After: 256 tests pass, 0 failures, 1 expected skip, 0 warnings

Key Learnings

1. Platform-Specific Tool Behavior

• Never assume cross-platform tools work identically
• Bats, while excellent, has platform-specific implementation differences
• Always test on target platforms, not just development environment

2. Root Cause Investigation Methodology

• Don't guess, investigate systematically
• Use bats -x for detailed execution traces
• Test hypotheses with isolated proof-of-concept code
• Distinguish between symptoms and root causes

3. Regex and Shell Compatibility

• Git Bash supports modern regex features when used correctly
• Issues often stem from tooling layer, not shell capabilities
• Platform differences in command parsing require careful attention

4. Test Design Best Practices

• Avoid external dependencies in tests (like python3 for JSON validation)
• Use heredoc for complex multiline input - most reliable approach
• Compare only stable file attributes - avoid access times
• Separate concerns - one test per scenario for better debugging

Recommended Patterns for Future Development

✅ DO: Use Heredoc for Complex Input

run "$COMMAND" file.txt - << 'EOF'
multiline
script
content
EOF

✅ DO: GPT's Pattern for Necessary Pipelines

run bash -c 'set -o pipefail; echo "$1" | "$2" --flags "$3"' \
    bash "$input" "$command" "$target"

❌ DON'T: Pipeline Across bash -c Boundary

run bash -c "printf '...' | command ..."  # Breaks on Git Bash

❌ DON'T: Compare Volatile File Attributes

[[ "$(stat file.txt)" == "$original_stat" ]]  # Access time changes

Files Modified

Core Library

• lib/eed_common.sh: Added missing regex patterns source
• lib/eed_regex_patterns.sh: Improved substitute regex fallback

Test Files

• tests/test_eed_single_param.bats: Printf pipeline → heredoc
• tests/test_eed_stdin.bats: Printf pipeline → heredoc + GPT pattern
• tests/test_safety_override_integration.bats: All patterns → GPT approach
• tests/test_ai_file_lifecycle.bats: Removed python3 dependency
• tests/test_eed_preview.bats: Fixed stat comparison + separated safety tests

New Infrastructure

• tests/test_printf_pipeline.bats: Comprehensive pipeline pattern validation

Impact and Metrics

• Test Reliability: 256/256 tests now pass consistently on Git Bash
• Warning Elimination: 0 BW01 warnings (previously multiple)
• Cross-Platform Compatibility: Patterns work on both Windows and Linux
• Maintainability: Cleaner test patterns, better separation of concerns
• Documentation: Comprehensive understanding of platform differences

Future Considerations

When Adding New Tests

1. Use heredoc approach for complex multiline input
2. Apply GPT's pattern when pipelines are absolutely necessary
3. Avoid comparing volatile file system attributes
4. Test on both platforms before considering complete

When Debugging Cross-Platform Issues

1. Use bats -x to see exact command execution
2. Create isolated test cases to verify hypotheses
3. Check for tool-specific implementation differences
4. Don't assume the issue is with your code - could be tooling

Monitoring

• Watch for new BW01 warnings as indicator of problematic patterns
• Ensure CI/CD tests both Linux and Windows environments
• Regular cross-platform test execution during development

This investigation demonstrates the importance of thorough cross-platform testing and systematic root cause analysis. The solutions we implemented not only fixed immediate issues but established robust patterns for future development.

Key Takeaway: When tools behave differently across platforms, the solution isn't to work around the differences, but to understand them deeply and adopt patterns that work reliably everywhere.

1.0.72 works well among all my terminals in Windows and Linux without any hacks. So please forget the fix in this article and try 1.0.72!
for version 1.0.51 or newer, you can simply add a new environment variable with CLAUDE_CODE_GIT_BASH_PATH=C:\Program Files\git\bin\bash.exe using Edit environment variables for your account feature on windows.

However, I stick with v1.0.45 for now, as I noticed 1.0.51 no longer support paste image in gitbash, which is a pity!

I just noticed this hack only works with version 1.0.45, so please stick with version 1.0.45 for now until we found another hack :D

Claude Code fails in Git Bash with path errors like:

Error: /usr/bin/bash: line 1: C:UsersDavid.WeiAppDataLocalTemp/claude-shell-snapshot-6ea5: No such file or directory

Root cause: os.tmpdir() returns Windows paths, Git Bash expects Unix paths.

Solution: Patch the CLI directly with sed.

# Create ~/bin/c
#!/bin/bash
REAL_CLAUDE=$(which claude)
basedir=$(dirname "$REAL_CLAUDE")
case `uname` in
    *CYGWIN*|*MINGW*|*MSYS*)
        if command -v cygpath > /dev/null 2>&1; then
            basedir=`cygpath -w "$basedir"`
        fi
    ;;
esac

CLAUDE_DIR="$basedir/node_modules/@anthropic-ai/claude-code"
CLI_FILE="$CLAUDE_DIR/cli.js"
BACKUP_FILE="$CLI_FILE.original"

# Backup once
if [ ! -f "$BACKUP_FILE" ]; then
    cp "$CLI_FILE" "$BACKUP_FILE"
fi

# Patch and run
cp "$BACKUP_FILE" "$CLI_FILE"
sed -i 's/\b\w\+\.tmpdir()/\"\/tmp\"/g' "$CLI_FILE"

cd "$CLAUDE_DIR"
exec node "cli.js" "$@"

chmod +x ~/bin/c
echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc

Now works:

c doctor
c --version  

The regex catches minified variable names. Patches fresh every run, so updates don't break it.

Hey fellow devs! Here’s a small but super useful Git trick for dealing with that annoying branch case sensitivity issue. You know the drill—someone creates feature/UserAuth, but you type feature/userauth. On a case-sensitive OS, Git tells you the branch doesn’t exist. On a case-insensitive OS like Windows or macOS, it’s worse—you switch to the wrong branch without realizing it. Later, you discover both feature/userauth and feature/UserAuth exist on GitHub. Ouch.

This is particularly painful when working with Windows or macOS, where the filesystem is case-insensitive, but Git isn't. Add in a mix of developers with different habits (some love their CamelCase, others are all-lowercase fans), and you've got yourself a daily annoyance.

The Fix

I wrote a little Git alias that makes checkout case-insensitive. It's basically a smarter version of git checkout that you use as git co. Here's what it does:

$ git co feature/userauth
⚠️ Warning: "feature/userauth" is incorrect. Switching to: "feature/UserAuth"
Switched to branch 'feature/UserAuth'

Nice, right? No more "branch not found" errors just because you got the case wrong!

Important Note ⚠️

This works in:

• Windows Git Bash (tested and used daily)
• Should work in macOS/Linux (though I haven't tested it - let me know if you try!)

But it won't work in:

• Windows CMD
• Windows PowerShell
• Any other Windows terminals

Why? Because it uses Bash commands and parameters. But hey, you're using Git Bash anyway, right? 😉

How to Install

Just run this in Git Bash:

git config --global alias.co '!f() {
  # If no args or help flag, show git checkout help
  if [ $# -eq 0 ] || [ "$1" = "-h" ] || [ "$1" = "--help" ]; then
    git checkout --help;
    return;
  fi;
  # If any flags are present (except -q or --quiet), pass through to regular checkout
  if [ $# -gt 1 ] || [[ "$1" == -* && "$1" != "-q" && "$1" != "--quiet" ]]; then
    git checkout "$@";
    return;
  fi;
  # Pass through if argument is a commit reference (HEAD, SHA, tag, etc)
  if [[ "$1" =~ ^HEAD([~^]|@{)[0-9]*$ ]] || # HEAD~1, HEAD^1, HEAD@{1}
     [[ "$1" =~ ^(FETCH_HEAD|ORIG_HEAD|MERGE_HEAD)$ ]] || # Special refs
     [[ -f ".git/refs/tags/$1" ]]; then # Tags
    git checkout "$@";
    return;
  fi;
  # Fetch and prune to ensure we have latest refs
  git fetch --prune --quiet;
  # Check both remote and local branches
  correct_branch=$(git branch -r | sed "s/^  origin\///" | grep -i "^$1$");
  if [ -z "$correct_branch" ]; then
    correct_branch=$(git branch | sed "s/^[* ] //" | grep -i "^$1$");
  fi;
  # If branch found with different case, warn and use correct case
  if [ -n "$correct_branch" ] && [ "$1" != "$correct_branch" ]; then
    echo "⚠️ Warning: \"$1\" is incorrect. Switching to: \"$correct_branch\"";
    git checkout "$correct_branch";
    return;
  fi;
  # Otherwise just pass through to regular checkout
  git checkout "$1";
}; f'

What's Cool About It?

• Finds your branch regardless of how you type the case
• Still works normally for everything else (files, creating branches, etc.)
• Shows you the correct branch name when you get the case wrong
• Auto-fetches to make sure it sees all remote branches

The best part? If it doesn't recognize what you're trying to do, it just passes everything to regular git checkout. So it won't break any of your normal Git workflows.

Real World Usage

I use this daily in a Windows-heavy dev team where we have branches like:

• feature/UpdateUser
• hotfix/FixLoginBug
• release/v2.0.0

And now I can type them however I want. Life's too short to remember exact branch capitalization!

Give It a Try!

If you're using Git Bash on Windows and tired of case sensitivity issues, give this a shot. It's one of those small tools that just makes your day a tiny bit better.

And hey, if you try this on macOS or Linux, let me know how it goes! Always curious to hear if these tricks work in other environments.