GNU bug report logs - #25388
ls-quotes: kills existing scripts reading "ls" -1 as input

Previous Next

Full log

Message #38 received at 25388 <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Andreas Schwab <schwab <at> linux-m68k.org>,
 25388 <at> debbugs.gnu.org
Subject: Re: bug#25388: Bug in ls, kills existing scripts reading "ls" -1
 as input
Date: Mon, 09 Jan 2017 11:53:12 -0800

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.