Notice that the solution is 'ls -1' (one, not "el"). That puts each file on it's own line. When you read it, you're assigning the whole line to a variable, not per whitespace-delimited word.
Infact you dont need an "ls -1" as such. A simple ls would do. In this case, the output of ls -1 and ls is the same. The output would be a file per line.
What ls does depends on the version of ls. I am aware of two behaviors:
ls defaults to one filename per line. (the original, but now rare behavior.)
ls examines stdout. If it is a tty, it switches to multiple filesnames per line, otherwise it puts 1 filename per line.
Since a pipe is not a tty, "ls|cat" will always be one filename per line. Ditto with using ls in a script in the manner shown above. If you really have an ls version with a third behavior, please tell us which version of unix you are using....after verifying that it is not an alias or something like that.
OK, you're wrong. It's a lot of stuff. At many places, the unix shell thinks in terms of words separated by spaces. Do:
echo `ls *`
You were beaten as soon as the ls finished. The backticks made the shell collect all of the output into one large line with a space between words. Then there is no way to tell the difference between:
"foot ball"
and
"foot" and "ball"
And what if a file has twenty spaces between two words in the filename? They get compressed to just one space.
The solution Jim posted avoids backticks. It also avoids using the "for" statement which loops on words. It is more what he avoided than what he used. His solution will work for embedded spaces and trailing spaces. But it will stumble on leading spaces which are very hard to support.