[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: L A Walsh
Subject: bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input
Date: Mon, 09 Jan 2017 11:53:12 -0800
User-agent: Thunderbird

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.

    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
        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
        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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]