> On Jun 13, 2015, at 10:26 AM, Julian Elischer <jul...@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 <mar...@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 <p...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
