Date: Mon, 10 Sep 2018 20:34:37 +0100 From: Matt Churchyard <churchers@gmail.com> To: Stefan Esser <se@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Getting valid JSON output with xo(1) Message-ID: <CANV9NzngF0A0EDCwMfJ_qDS20aBCPfjem=K%2Bm7-e_2ZDsnfkCA@mail.gmail.com> In-Reply-To: <228b2a88-6134-c8c2-a28d-cb09cbc03ef6@freebsd.org> References: <CANV9Nz=3aOd5RM9KyTfz-1_%2BEnffKEOVQbYZxJY=i9_x0gorpA@mail.gmail.com> <ef40f50a-3a80-cc8d-5e9e-4bf40f8ff604@freebsd.org> <CANV9NzmyPoDk6qN19wW0SvzPu4aN9Ypsj9a_ttS2gp1EmqHUwQ@mail.gmail.com> <CANV9Nznba3ua_W17BnGOpiEcsW5pp-Jk4vFOcJxYnzVbUfWQ6w@mail.gmail.com> <228b2a88-6134-c8c2-a28d-cb09cbc03ef6@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks Stefan
For now I=E2=80=99ve altered my code to output the extra characters when ne=
eded,
and switch {} to [] using tr.
I may raise an issue with the libxo guys and see what happens, as it seems
to be a bit of a pain that I have to go through all this to generate a
fairly simple JSON document.
Matt
On Sun, 9 Sep 2018 at 17:13, Stefan Esser <se@freebsd.org> wrote:
> Am 09.09.18 um 16:10 schrieb Matt Churchyard:
> > Hi Stefan,
> >
> > I did include the commands used to generate the sample output in my fir=
st
> > message. I am using the xo(1) utility, not libxo directly. I did mentio=
n
> > this might not be the right list (you've obviously assumed I'm directly
> > using libxo), but it does seem to me this is more an issue with the xo
> > utility, rather than just a usage error.
>
> Hi Matt,
>
> I'm sorry - you are of course right and there was everything required to
> reproduce the effect in your previous mail ...
>
> > I've since looked further into the libxo documentation, and as you
> suggest,
> > it does seem that I need to be using the xo_open_list/xo_close_list
> > functions to generate the right output. However, these are not exposed
> via
> > xo(1). The documentation for xo_open_list describes how it is used to
> > create lists of individual entities, whereas the "l" modifier (which is
> all
> > I can access via xo(1)) creates "leaf lists", which are only for single
> > values. As such, it seems there's a big hole in the functionality of
> xo(1),
> > meaning it can only really be used to create very simple JSON documents=
.
>
> The following code fragment in libxo.c does suppress the terminating
> new-line
> character on purpose if depth !=3D 0:
>
> case XO_STYLE_JSON:
> pre_nl =3D XOF_ISSET(xop, XOF_PRETTY) ? "\n" : "";
> ppn =3D (xop->xo_depth <=3D 1) ? "\n" : "";
>
> xo_depth_change(xop, name, -1, -1, XSS_CLOSE_CONTAINER, 0);
> rc =3D xo_printf(xop, "%s%*s}%s", pre_nl, xo_indent(xop), "", ppn=
);
> xop->xo_stack[xop->xo_depth].xs_flags |=3D XSF_NOT_FIRST;
> break;
>
> The reason appears to be, that closing the outer level construct will pri=
nt
> a new-line before other text. If you omit the second "xo --wrap",
> everything
> will look OK. And if you test with --depth 0, you'll see that the output =
is
> actually terminated with a new-line.
>
> > As I mentioned in my first message, it looks like xo(1) could do with
> some
> > way to open/close lists, similar to the --open/--close options, and a w=
ay
> > to specify that a single call should be output as a part of a list.
>
> I do not see a better solution than adding an "echo" command between call=
s
> to "xo --wrap", as you already mentioned as a work-around. This is simple=
r
> than adding list_open/close functions and it has the same effect, if you
> know that you are emitting JSON.
>
> Best regards, STefan
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANV9NzngF0A0EDCwMfJ_qDS20aBCPfjem=K%2Bm7-e_2ZDsnfkCA>