EST. 2026 — Notes from real server work SYSADMIN · SECURITY · AI · DIRECTADMIN Issue 01
THE SYSADMIN ALMANAC
Home / Linux / Writing Scripts on Windows for Linux — Two File Cleanup Traps
Linux

Writing Scripts on Windows for Linux — Two File Cleanup Traps

by Ton-Or ·16 Jul 2026·6 min read
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.

What actually happened

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.

Root causeWrite on WindowsUsed to d:\ paths→scp to Linux→\ = ordinary characterWhole path = filename→/tmp/D:\...jsonMonitor alerts

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).

Keep cleanup in the same chain

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

  1. Scripts running on the server must use Linux paths exclusively, with no drive letters or backslashes.
  2. Before uploading, grep for Windows paths and reject the upload if any are found.
  3. Delete token/payload/helper files in the same ssh chain that runs them. Don't make deletion a separate step.
  4. 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.

Get a quote

Hit something like this? Stuck somewhere?

Come trade notes on the LinuxThai board

→ Continue on the board

Comments 0

No comments yet — be the first