Writing Scripts on Windows for Linux — Two File Cleanup Traps
The machine that opens a path determines which syntax to use — scripts running on Linux must use POSIX paths throughout, without Windows backslashes mixed in. It sounds minor, but one mistake leaves stray files in /tmp that I have to track down and delete.
I often work by "writing scripts on a Windows machine, then using scp to run them on a Linux server" — sometimes to generate reports, sometimes to fetch data. I write them in Python/PHP/Bash, upload them, run them, then delete them. It seems straightforward, but two things have caught me out repeatedly, enough that I made personal rules for them. I wanted to share them for anyone working the same way.
Trap 1: Windows paths embedded in scripts running on Linux
On Linux, \ is an ordinary character allowed in filenames, not a directory separator as it is on Windows. When I accidentally embedded a path like d:\data\out.json in a script and ran it on Linux, it created a file named D:\data\out.json (the whole thing was a single filename) in /tmp.
This strange filename matched the server's file-integrity monitor's "suspicious filename" rule and triggered an alert — I wasted time checking whether the server had been hacked, when it was just a stray backslash.
My rule: the machine that opens the path determines its syntax. Scripts that will run on the server must use Linux paths exclusively (/tmp/out.json, /home/user/...), with no drive letters or backslashes.
Prevent mistakes with a pre-upload check
Don't rely on memory. Before every scp, grep for drive-letter paths and reject the upload if any are found:
# ก่อน upload — เจอ path แบบ Windows = ไม่ส่ง
if grep -nE '[A-Za-z]:\\|[A-Za-z]:/' deploy.sh; then
echo "REFUSE: พบ Windows path ในสคริปต์ที่จะรันบน Linux"
exit 1
fi
Putting this line at the top of the deploy script catches the problem at the source.
Trap 2: Forgetting to delete temporary files on the server
This kind of work often creates intermediate files — payloads, .token files containing secrets, and the helper script itself. If I forget to delete them when the job is done, they stay on the server, causing two problems: clutter and a security risk (especially files containing tokens/passwords).
Don't leave deletion as a separate step for later, because if the script dies midway, that step won't run — combine upload -> run -> delete in a single ssh command chain, then finish with ls /tmp to confirm that everything has been cleaned up.
scp payload.json runner.sh user@host:/tmp/
ssh user@host 'set -e
cd /tmp
bash runner.sh payload.json > /tmp/run.log 2>&1
rm -f /tmp/payload.json /tmp/runner.sh /tmp/*.token
echo "--- เหลืออะไรใน /tmp บ้าง:"; ls -la /tmp | grep -E "payload|runner|token" || echo clean'
My personal rules
- Scripts running on the server must use Linux paths exclusively, with no drive letters or backslashes.
- Before uploading, grep for Windows paths and reject the upload if any are found.
- Delete token/payload/helper files in the same ssh chain that runs them. Don't make deletion a separate step.
- Finish with ls to confirm that nothing has been left behind.
These two issues seem trivial, but they have cost me real troubleshooting time, especially the stray files in /tmp that made me suspect an intrusion when the cause was just a misplaced backslash. If you regularly work across Windows→Linux, setting these two rules from the start is easier than fixing the mess later. If I've left anything out or made any typos, I'll come back and correct them later.
Want us to set this up?
Get help with server setup, configuration, migration, or troubleshooting. Save time for the work that matters.
Hit something like this? Stuck somewhere?
Come trade notes on the LinuxThai board



Comments 0
No comments yet — be the first