svn commit: r284198 - head/bin/ls

[Warner Losh]

> On Jun 13, 2015, at 10:26 AM, Julian Elischer <julian at FreeBSD.org> wrote:
> 
> On 6/13/15 10:49 AM, Steve Kargl wrote:
>> On Fri, Jun 12, 2015 at 08:43:09PM -0400, Alexander Kabaev wrote:
>>> On Wed, 10 Jun 2015 01:27:39 +0000 (UTC)
>>> Marcel Moolenaar <marcel at FreeBSD.org> wrote:
>>> 
>>>> Author: marcel
>>>> Date: Wed Jun 10 01:27:38 2015
>>>> New Revision: 284198
>>>> URL: https://svnweb.freebsd.org/changeset/base/284198
>>>> 
>>>> Log:
>>>>   Convert ls(1) to use libxo(3).
>>>>      Obtained from:	Phil Shafer <phil at juniper.net>
>>>>   Sponsored by:	Juniper Networks, Inc.
>>>> 
>>> <SKIP>
>>> 
>>> This broke all code that pipes output of the ls command to pipeline,
>>> such as 'ls | wc -l'. ls never exits and never output anything. Is
>>> there any purpose to libxo other than breaking stuff, which it achieves
>>> so splendidly?
>>> 
>> -1 for libxo, which also makes code almost unreadable.
> +1 of the -1
> 
> my personal vote is to revert all libxo changes and banish it from /usr/src.
> 
> "not the way to solve the problem  in question".

It isn’t even wrong….

I think that we shouldn’t integrate any more libxo stuff until all the known
bugs in the stuff that’s already been converted is fixed.

For example, gstat’s ‘q’ function now needs a <bleeping> carriage return
before it will quit. That’s insane. And the twisty maze of modifications
has made it rather an uber-pita to figure out WTF I need to do to un-F
this up.

But back to the topic at hand. libxo for ls? Really? WTF were you
thinking? I know the cat -v paper is a bit of an extreme viewpoint,
but all the libxo integration can be used a poster child for Pike’s
worries…

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20150613/cc658a63/attachment.sig>