From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 00:42:59 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10BA9D9F; Fri, 15 Aug 2014 00:42:59 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id EFB152836; Fri, 15 Aug 2014 00:42:58 +0000 (UTC) Received: from u10-2-16-021.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 5992E346DE46; Thu, 14 Aug 2014 17:42:58 -0700 (PDT) Message-ID: <53ED57F2.5020808@mu.org> Date: Thu, 14 Aug 2014 17:44:34 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Phil Shafer , Warner Losh Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML References: <201408141640.s7EGe422096656@idle.juniper.net> In-Reply-To: <201408141640.s7EGe422096656@idle.juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , John-Mark Gurney , "Simon J. Gerraty" , arch@freebsd.org, Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 00:42:59 -0000 On 8/14/14 9:40 AM, Phil Shafer wrote: > Warner Losh writes: >> My question for people advocating this method: Why not require all >> commands that generate this kind of output to support a standard >> command line option that causes the command to print nothing and >> return 0 if it supports reporting, or anything else if it doesn't >> (return 0 with output, or return non-zero with or without output). > It's a chicken and egg problem. I can't call the command with the > option until I know that command can handle the option without > generating an error, a core file, or rebooting the box. Until I > know what the command will do, I can't invoke it safely. > > There's also the issue of find an option that all commands are not > using, given that I can't change options for existing commands. > > I don't understand the need to query these programs for support of the option. Can you explain in more detail? -Alfred