Stop getting burned when your shell script globbing hits hidden files

Technical Briefing | 9/4/2026

We have all been there. You write a loop to process a batch of files in a directory, use a star glob, and everything works fine until it doesn’t. Specifically, when your automation encounters a filename starting with a dot, your neat little for-loop suddenly skips it or, worse, expands the dot itself into the file list. This bit me in production back in 2012 when a backup script silently ignored hidden configuration files because dotfiles are invisible to default globbing behavior.

Why Bash keeps secrets from your loops

The shell treats dotfiles as special by design. Unless you explicitly enable dotglob in Bash, the asterisk wildcard intentionally ignores files beginning with a period. It is a safety feature that prevents you from accidentally nuking your .bashrc or .git directory when you run rm * in a project folder. But when you are writing automation that needs to actually archive or move everything, this safety feature becomes an annoying hurdle that hides files in plain sight.

shopt -s dotglob
for file in *; do
[ -f "$file" ] && process "$file"
done
shopt -u dotglob

• shopt -s dotglob changes the behavior for the current shell session only
• Always use quotes around the variable to handle filenames with spaces
• The -f test is mandatory to prevent the loop from trying to process directories
• Reset the setting with shopt -u if you are running in a long-lived environment

Most tutorials skip the dotglob nuance entirely, which is why your scripts break when they move from testing with standard files to production environments littered with hidden metadata. You could use find -maxdepth 1, but for simple tasks, shell globs are faster and easier to read. Just remember that if your shell script is running in a cron job or a subshell, you need to turn the switch on explicitly within that environment or you will keep chasing ghosts.