Wouter Verhelst <w...@uter.be> writes:
> With the ls version before this change, J. Random Inexperienced Hacker
> would see that there are multiple file names on a single line in the
> output of ls, decide that ls output is too difficult to parse, and move
> on to something else (probably find or some such).
>
> With the ls version after this change, J. Random Inexperienced Hacker
> might decide that the quoted nature of the ls output is *ideal* for
> parsing, add something along the lines of
> INPUT=$(ls /path/to/input/directory)
> to his script, and think he's safe against filenames with spaces in them
> ("because ls quotes output").J Random Inexperienced Hacker already does this in the present day though. > The default enabling of the -C option when ls is connected to a terminal > doesn't do harm (and in fact discourages this kind of unsafe behaviour). > However, showing characters that aren't part of a filename in ls output > *by default* is confusing and (as the above shows) potentially > dangerous. ls already showed characters that aren't part of a filename *before* this change: $ ls /tmp/a a???????????? a???????????? Neither filename contains a question mark, and the filenames are actually not identical. One could argue that "ls" should give an error when it encounters any character that might need quoting instead of enabling quoting by default. (And this is probably also true when output does not go to a terminal: at least printing \n as part of a filename is pretty much always broken.) Ansgar
