| commit | 902f2203f0bc38de25dffd885ca837fe59e4a3fb | |
| author | Eric Blake <eblake@redhat.com> | |
| Tue, 30 Jul 2019 20:58:06 +0000 (30 15:58 -0500) | ||
| committer | Eric Blake <eblake@redhat.com> | |
| Tue, 30 Jul 2019 21:42:50 +0000 (30 16:42 -0500) | ||
| tree | eaca31171d0172a382e82fe81e5a08b9dc5befa8 | treesnapshot (tar.gz zip) |
| parent | 9b3c740a326b49ac4c805ab681d93c9ab16920f6 | commitdiff |
tests: Accommodate qemu-img 4.1 output change
Where qemu-img 4.0 used to say 'virtual size: 100M', the 4.1 release
now says 'virtual size: 100 MiB'. Similarly, '5.0G' turned into '5
GiB'. But rather than worry about potential future changes to the
human-readable output, we can just use --output=json (at which point
we no longer even have to force qemu-img to the C locale, which we
were not even doing consistently). It might be slightly more robust
to find our specific information using jq, but for now a grep of the
output json is still reliable enough for our needs.
If the '\b' is a problem on BSD, we could use '([, ]|$)' instead. Or
that's where jq would make it easier to parse off a given number
without worrying about what comes after the number.
Signed-off-by: Eric Blake <eblake@redhat.com>
Where qemu-img 4.0 used to say 'virtual size: 100M', the 4.1 release
now says 'virtual size: 100 MiB'. Similarly, '5.0G' turned into '5
GiB'. But rather than worry about potential future changes to the
human-readable output, we can just use --output=json (at which point
we no longer even have to force qemu-img to the C locale, which we
were not even doing consistently). It might be slightly more robust
to find our specific information using jq, but for now a grep of the
output json is still reliable enough for our needs.
If the '\b' is a problem on BSD, we could use '([, ]|$)' instead. Or
that's where jq would make it easier to parse off a given number
without worrying about what comes after the number.
Signed-off-by: Eric Blake <eblake@redhat.com>