Spaces are not a problem there. Filenames with a leading dash would cause a problem because they'd be processed as a command option. Using grep -lE -- ... would protect against that. Other than that, the only filename character that will cause a problem with that command is a newline. Since grep -l output is "%s\n", filename, if the filename itself contains a newline, it's impossible to distinguish between a newline from a filename and a newline added by grep to separate filenames.

In my humble opinion, spaces in filenames are not a big deal. However, anyone who uses tabs or newlines in a filename deserves what they get, , because most UNIX tools are designed for text files, which are defined to consist of newline-terminated records with tab-delimited fields.

The * can handle any valid filename just fine. The shell performs pathname expansion (aka file globbing) of wildcards like * and ? after field splitting (which is where whitespace, specifically IFS whitespace characters, can be problematic). Since field splitting has already occurred by the time * is expanded, it's not possible for a space to cause the filename to be split into multiple words. Pathname expansion is the penultimate step in the shell's parsing sequence (only quote removal occurs afterward, which is nothing but the removal of single and double quotes which were present at the start of processing).

For the same reason, for filename in *; do .... done can safely handle any valid filename, regardless of how many spaces, tabs, newlines, or shell metacharacters (e.g. $) it may contain, because the resulting pathname arrives so late in command line processing that the parsing phases which recognize special characters (command substitutions, parameter expansions, field splitting, etc.) have all already completed.

Regards,
Alister