[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument synt
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax |
Date: |
Mon, 6 Feb 2017 10:20:17 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
* Markus Armbruster (address@hidden) wrote:
> "Dr. David Alan Gilbert" <address@hidden> writes:
>
> > * Markus Armbruster (address@hidden) wrote:
> >> "Dr. David Alan Gilbert" <address@hidden> writes:
> >>
> >> > * Markus Armbruster (address@hidden) wrote:
> [...]
> >> >> === Structured values ===
> >> >>
> >> >> The dotted key convention messes with KEY syntax to permit structured
> >> >> values. Works, but the more conventional way to support structured
> >> >> values is a syntax for structured values.
> >> >>
> >> >> An obvious one is to use { KEY=VALUE, ...} for objects, and [ VALUE,
> >> >> ... ] for arrays. Looks like this:
> >> >>
> >> >> -drive 'driver=quorum,
> >> >> child=[{ driver=file, filename=disk1.img },
> >> >> { driver=host_device, filename=/dev/sdb },
> >> >> { driver=nbd, host=localhost } ]'
> >> >>
> >> >> Again, lines broken and indented for legibility; you need to join them
> >> >> for actual use.
> >> >>
> >> >> There's a syntactic catch, though: a value of the form [ ... ] can
> >> >> either be an array or a string. Which one it is depends on the type of
> >> >> the key. To parse this syntax, you need to know the types, unlike JSON
> >> >> or traditional QemuOpts. Unless we outlaw strings starting with '{' or
> >> >> '[', which feels impractical.
> >> >
> >> > I don't understand why [ could imply a string.
> >>
> >> Consider
> >>
> >> -drive 'driver=quorum,
> >> child=[{ driver=file, filename={"foolish":"name"} },
> >> { driver=host_device, filename=/dev/sdb },
> >> { driver=nbd, host=[::1] } ]'
> >>
> >> Three KEY=VALUE have their VALUE start with '[' or '{':
> >>
> >> * child=[{ driver=file, ...
> >>
> >> This is an array, not a string, because child is an array.
> >>
> >> * host=[::1]
> >>
> >> This is a string, not an array containing the string "::1", because
> >> host is a string.
> >
> > Why is that accepted as valid input? Can't that just spit a
> > 'I wanted a string not an array' ?
>
> Because "[::1]" is a perfectly valid string.
>
> It's also a valid array. Unless the parser knows what type to expect
> here, it cannot decide how to parse it. That's why I wrote "to parse
> this syntax, you need to know the types".
I think that's fine; the parser would just parse something starting with
a [ as an array, always. You just define that and then everyone knows
that you'd better " it if you've got a [ in your string.
Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- [Qemu-block] Non-flat command line option argument syntax, Markus Armbruster, 2017/02/02
- Re: [Qemu-block] Non-flat command line option argument syntax, Eric Blake, 2017/02/02
- Re: [Qemu-block] Non-flat command line option argument syntax, Eric Blake, 2017/02/02
- Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Dr. David Alan Gilbert, 2017/02/02
- Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Max Reitz, 2017/02/03
- Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Markus Armbruster, 2017/02/04
- Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Paolo Bonzini, 2017/02/04
- Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Markus Armbruster, 2017/02/04
- Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Paolo Bonzini, 2017/02/04
Re: [Qemu-block] Non-flat command line option argument syntax, Daniel P. Berrange, 2017/02/03
Re: [Qemu-block] Non-flat command line option argument syntax, Peter Krempa, 2017/02/03
Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Richard W.M. Jones, 2017/02/03