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.