No script should parse ls output, though. There are always better ways than parsing ls output.

The POSIX specification for ls's output is sufficiently precise[1] that it is quite reasonable to rely upon it. As a result, many scripts from a diverse array of vendors do so. A cursory glance at my home Ubuntu server has 'ls' invoked in many of the base package installation scripts and more besides.

One could sometimes use find(1) of course, but it has different semantics and output to ls unless you jump through some very silly command-line hoops that will make you say "should've just used ls".

As for the stat(1) program, which might be an alternative for individual files, it is not standardised, is not portable, and is in fact totally incompatible between GNU coreutils and BSD userland (including Mac OS).

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls...

Let me quote that thing you linked to:

"As with many of the utilities that deal with filenames, the output of ls for multiple files or in one of the long listing formats must be used carefully on systems where filenames can contain embedded white space."

POSIX is such a system. If you try to parse the filenames output by ls, it will break when you encounter a filename with whitespace in it. Use a shell glob instead—it will actually work right.

A shell glob cannot tell you the size, owner, permissions, timestamps of a file. For that .. oh look! There's ls(1). Which, by the way, spits out whitespace it sees just fine, unless you specified -q or implied it with output to a tty. If some code can't handle the result, it's that code that is broken. Tip: the only really problematic character is a newline; if you think you could be seeing those, you can still deal with it programatically, but I use find(1).

In the meantime, I recommend you try deleting /bin/ls from your system and then filing bugs against everything that breaks.

Alright, here's an example:

  touch 'file with spaces'
  for file in $(ls); do
    rm -- "$file"
  done

This will not work, because $(ls) will get expanded to three items, not one. rm will be called on the files "file", "with", and "spaces"...which is not what was intended.

Now do this:

  touch 'file with spaces'
  for file in *; do
    rm -- "$file"
  done

This works correctly.

  ls -Q

this will quote the file name for pipe operation

Still doesn't work.

  touch 'file with spaces'
  for file in $(ls -Q); do echo "$file"; done

This prints:

  "file
  with
  spaces"

s/you're/your/