From owner-freebsd-current@freebsd.org Mon Nov 16 09:47:02 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2A8BA2E573 for ; Mon, 16 Nov 2015 09:47:02 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD713133A for ; Mon, 16 Nov 2015 09:47:02 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 747BA78A1 for ; Mon, 16 Nov 2015 10:46:59 +0100 (CET) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> From: Jan Bramkamp Message-ID: <5649A612.3090905@rlwinm.de> Date: Mon, 16 Nov 2015 10:46:58 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 09:47:03 -0000 On 15/11/15 13:54, Dan Partelly wrote: > 2. I have seen the idea that this makes the information dumped by utilities in the base easily accessible programatically. OK, maybe it does , but > it doesn't fit with the current paradigm of "tool | filter | tool” at all. There are no tools able to accept JSON and filter it in any meaningful way, and I > dont see too many ppl changing their code to read JSON instead of text. I don't even see the base tools changing. This output may be useful in corner cases only. There is jq [https://stedolan.github.io/jq/]. You can think of it as sed + awk + grep for streams of JSON objects.