bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input

[L A Walsh]

Eric Blake wrote:
> But that's EXACTLY what POSIX has specified, because it has been
> existing practice for YEARS.
---
        A bit louder Eric, you can't be heard.


> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html
> "STDOUT
>     The default format shall be to list one entry per line to standard
> output; the exceptions are to terminals or when one of the -C, -m, or -x
> options is specified. If the output is to a terminal, the format is
> implementation-defined.
---
        Perhaps you could read my email -- especially the part
where I listed the alias I use for running 'ls'.


> And POSIX merely codified existing practice (this is nothing new - it
> has been this way since the 70's)
---
        Not anymore.

        Breaking "rm -fr ." wasn't an existing practice except
at BSD-using dists (like BSD & SunOS).  While Solaris was SysV, 
since it was bought up, it has changed.


> The GNU Coding Standards explicitly discourage NEW programs from
> changing default behavior based solely on whether stdout is a tty or
> not, but existing programs like ls are grandfathered in to have their
> historical behavior, which predates the GNU Coding Standards.
---
        Good -- that makes the issue pretty black & white.

	Given those standards, then adding a NEW behavior that 
does change the output depending on destination being tty or not
would be "explicitly discouraged".  Making the matter more clear
is that it is NOT a case of grandfathering in a "historic behavior"


> I agree that it is not nice to change output merely based on the type of
> fd that stdout is, and GNU Coding Standards agrees in general.  But like
> it or not, that's precisely what happens in ls due to
> backwards-compatibility.
---
        The old behavior of multi or single columns may be
historical and backwards compat -- I have no problem with that.

*However*, the new behavior of adding new-shell-encoded
output as the default is not historical.  It encodes output
for bash and other new shells -- hindering cut&paste to other
programs.