Date: Thu, 14 Aug 2014 10:50:02 -0600 From: Warner Losh <imp@bsdimp.com> To: Phil Shafer <phil@juniper.net> Cc: Marcel Moolenaar <marcel@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net>, arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch <freebsd-arch@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <B123014F-F006-4EB2-BA13-23B6596BCB2A@bsdimp.com> In-Reply-To: <201408141640.s7EGe422096656@idle.juniper.net> References: <201408141640.s7EGe422096656@idle.juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Aug 14, 2014, at 10:40 AM, Phil Shafer <phil@juniper.net> 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.
If a userland command reboots the box in response to bad command
line options, that’s not your problem to fix: that’s a security issue
that needs to be fixed regardless of the method you chose. If the command
creates a core file, that’s a bug in that command. The command
could very easily create a core file when you call it with a valid
set of options too. Generating an error is 100% fine: in fact I count
on that happening.
> 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.
In my opinion, there’s no chicken and egg problem.
I specifically proposed a long option that isn’t present in any command,
and is likely to generate errors or at least output. The reason I proposed
the long option was so that 2 lines of code could be added to programs
that support it:
in some header:
#define LONG_OPTION_DEFINE “—supports-xml-output"
#include <some-header.h>
...
int main(int argc, char **argv)
{
/* local variables here */
if (argc == 2 && strcmp(argv[1], LONG_OPTION_DEFINE) == 0)
exit(0);
}
Which wouldn’t interfere with any other command line parsing these
programs do. —supports-xml-output isn’t likely a valid set of options
for any program that exists today, except for those that support xml.
The protocol is simple: redirect stdout and stderr to pipes, invoke
the command, if the exit status is 0 and there’s no output on the pipes,
then the command supports your protocol. If there’s output, or if the
exit status isn’t 0, then the program doesn’t.
Warner
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJT7Oi6AAoJEGwc0Sh9sBEAYlUQANQHwNrH68xkotZi27YYQthA
ETaicmy1rterMVV16yoPAUVYxj3fNtMFiajlbDhQtbopPu0HYLJHq6aH4Y6lTVzm
uQSfsSnlMbQthiaN0TdalkWKXar+hTLCz5TXYMyofvfV1NLELvzvHyq1C1mXw4NW
0V7E+5fouZxc/SBgUFace8ZMKbMRL9PSj1dnI96zMQ28WwCeq4HbH297tVwV1sRk
OmolUKJSONAczauPdoS9t7v5SsRPhVCfBE7Znm0UwEyKUEcKuTYd/VdFOxQw5Mkg
3ThYGHlgoJKNC3ztIcUxGqSUMJrQ3OUxcArzwXh/MGH/hQbz+01bk37ZXO95TvzT
aP7NKDot0Yc9wf2R/J6uo21gflQCSBq94ZKJUxJbZY5ZyWDpWtaKrKsh8jvvb2j5
vzKQYmUFLsYuM9BhJVnXQryzgAL3geB4GPCkAmd8NfNFp2vvMAgNygjzDpxWTUzN
uggBj5mxfX1zowKqi4DPqpHjSWpsF5PIH1GNv+KWDEkDtfj0UcOHM9dX2LFR939R
uNzdPwRpDSonbfrMVzkOAOJtqTTgqq2DpjsCA2+5zF1k+/k09GU6zcSiDNdtNBeM
K7pq7/ZlwqkuvXmfzV+++mzS0I4B0JAOFIHNGgK3rGBDM4eqfCJJYJaaaiBZeSGj
ks1FWXpH2YXW0BHLdcMR
=RWuk
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B123014F-F006-4EB2-BA13-23B6596BCB2A>