$ mkdir "hi there"
$ mkdir "how are you"
$ ls -l
total 8
drwxr-xr-x 2 xxxxxxxx xxxx 4096 Jun 26 14:54 hi there
drwxr-xr-x 2 xxxxxxxx xxxx 4096 Jun 26 14:54 how are you
$ for f in $(ls); do echo $f; done
hi
there
how
are
you
then reset it later. Perhaps store existing IFS in a variable so you can put it back. The \n vs actual line feed has to do with an edge case in cygwin and dos files.
... works better for the easy edge cases, but still probably has some issues. Personally I think klodolph called it; once you get into anything that has a few interesting edge cases bash becomes pretty unwieldy.
The easiest way is still: for file in *; do ...; done
This works fine with spaces and other strange characters, no need to come up with more complicated ways.
If you must use find, the correct way is really tricky and uses obscure bash features like settings IFS to the empty string to split on null bytes and process substitution so that the loop doesn't run in a subshell (which would prevent it from modifying variables in the current environment):
while IFS= read -r -d '' file; do
...
done < <(find /tmp -type f -print0)
I like that, I've never thought of or seen it, although it should've been intuitively obvious given how bash expansion works.
I think this demonstrates the point pretty well though - it takes a discussion among three of us before arriving at something that works moderately well, and we found four fairly different ways of doing it...
is both much easier and much safer than piping the output of ls.
It does the correct thing with filenames containing spaces or weird characters, and the intent is much more visible, so there is really no reason to use $(ls).
Maybe I'm overlooking something...but why wouldn't this work:
for file in $(ls); do {<looped command>}; done