Stop getting burned by globbing characters in your automated filenames

Technical Briefing | 9/16/2026

We have all been there. You write a script to sweep up some old log files, you use a simple wildcard like *.log, and everything works great until someone decides to name a file with a literal asterisk in it. Then your script suddenly tries to delete everything in the directory or, worse, goes after files it has no business touching. It is a classic trap that I have seen take down production build servers more than once.

Why shells love to expand things before you are ready

The shell is doing exactly what you told it to do. When you pass a glob to a command, the shell expands it into a list of filenames before the command ever sees them. If you have filenames that contain spaces, quotes, or even glob characters, this process breaks your logic entirely. Relying on simple expansions without proper escaping or null-delimited inputs is just waiting for a race condition or a malicious filename to ruin your day.

find /var/log -maxdepth 1 -name '*.log' -print0 | xargs -0 rm -f

• Using -print0 and -0 handles spaces and special characters perfectly
• The find command avoids the shell globbing issue by executing directly
• Always quote your paths to prevent unexpected splitting

Stop using for i in *.log if you care about the integrity of your filesystem. It is fragile and breaks the moment a developer gets creative with naming conventions. If you switch to the find and xargs combo, you gain predictable behavior every single time. It feels like a small change, but it is the kind of defensive scripting that keeps you from getting paged at 3 AM for a catastrophic deletion event.

Next time you feel tempted to use a quick shell glob for automation, pause and ask yourself if you really want the shell interpreting those characters. If you keep the input stream null-delimited, you can stop worrying about what kind of chaos someone might name their files.