If you want to ensure that the script has been given a viable working directory, then $1 should be tested to confirm that it's non-empty and a directory. In that instance, blindly substituting a string in that way can be dangerous.

You are mistaken about the for f in * ... construct. Since pathname expansion occurs after field splitting, the expansion of * is absolutely safe with regard to IFS characters (by default, space, tab, and newline).

Ironically, the statement you replaced it with does not handle spaces correctly in all cases. If ls prints a filename with leading or trailing spaces, read will discard those, yielding either a non-existent file or a different file. Further, if the filename ended with a backslash, that backslash would be stripped and the next filename in the list, if any, would be appended. while IFS= read -r f fixes both issues.

Demonstration:

Code:

$ touch 'a1\' a2 '   spaces   '
$ # CORRECT RESULT
$ for f in *; do printf ':%s:\n' "$f"; done
:a1\:
:a2:
:   spaces   :
$ # ERRONEOUS HANDLING OF LEADING/TRAILING WHITESPACE AND TRAILING BACKSLASH
$ ls | while read f; do printf ':%s:\n' "$f"; done
:a1a2:
:spaces:
$ # FIX ONLY THE BACKSLASH
$ ls | while read -r f; do printf ':%s:\n' "$f"; done
:a1\:
:a2:
:spaces:
$ # FIX ONLY THE SPACES
$ ls | while IFS= read f; do printf ':%s:\n' "$f"; done
:a1a2:
:   spaces   :
$ # FIX BOTH
$ ls | while IFS= read -r f; do printf ':%s:\n' "$f"; done
:a1\:
:a2:
:   spaces   :

You are correct in that there may be a limit to how many files the pathname expansion in the for-loop list can handle, but if it's sufficient (usually is) for the task at hand, it's the simplest and safest method.

Regards,
Alister