← ./articles

Writing Windows Paths to JSON from Git Bash? Avoid inline node -e and printf

Writing JSON from Git Bash is usually harmless until the JSON contains Windows paths.

Then this:

{ "path": "<windows-path>\\tools\\cache\\**" }

can accidentally become a string with tab characters, because \t is interpreted while crossing shell and command-line boundaries.

The safest fix is simple: do not write JSON with complex backslashes through inline node -e or printf. Put the logic in a script file.

The failure

This kind of command is fragile:

node -e 'const x = { path: "<windows-path>\\tools\\cache\\**" }; console.log(JSON.stringify(x))'

Depending on quoting layers, the backslashes can be interpreted before Node receives the intended string.

The same can happen with printf:

printf '{"path":"<windows-path>\\tools\\cache\\**"}' > config.json

The file may contain tab characters instead of literal \t.

Why script files are safer

Write a small JavaScript file:

const fs = require("fs");

const config = {
  path: "<windows-path>\\tools\\cache\\**",
};

fs.writeFileSync("config.json", JSON.stringify(config, null, 2));

Then run:

node write-config.js

The shell only passes the script filename to Node. It does not reinterpret the JSON string contents.

PowerShell alternative

If you are already in PowerShell, use structured objects:

@{
  path = "<windows-path>\tools\cache\**"
} | ConvertTo-Json | Set-Content -Encoding utf8 config.json

This avoids hand-written JSON escaping.

Checklist

Use a script file when JSON contains:

  • Windows paths
  • backslashes
  • glob patterns
  • regular expressions
  • nested quotes

Avoid inline node -e, printf, or long one-liners for those cases.

Summary

If Git Bash turns Windows path backslashes into tabs or broken escapes, stop fighting the shell.

Move the JSON creation into a .js or .ps1 file. Let the interpreter read source code from disk instead of asking the shell to preserve every backslash through multiple parsing layers.

References