| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We often used a pattern like if (!FLAGS_SET(flags, SD_JSON_FORMAT_OFF)),
which is rather verbose and also contains a double negative, which we try
to avoid. Add a little helper to avoid an explicit bit check.
This change clarifies an aditional thing: in some cases we treated
SD_JSON_FORMAT_OFF as a flag (flags & SD_JSON_FORMAT_OFF), while in other cases
we treated it as an independent enum value (flags == SD_JSON_FORMAT_OFF).
In the first form, flags like SD_JSON_FORMAT_SSE do _not_ turn the json
output on, while in the second form they do. Let's use the first form
everywhere.
No functional change intended.
Initially I wasn't sure if this helper should be made public or just internal,
but it seems such a common pattern that if we expose the flags, we might just
as well expose it too, to make life easier for any consumers.
|
| |
|
|
| |
This makes it possible to process continuous replies with jq etc.
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently, when SD_JSON_FORMAT_OFF is set in verb_call, the json format
flags are set to SD_JSON_FORMAT_PRETTY_AUTO|SD_JSON_FORMAT_COLOR_AUTO,
rather than or'ing those flags in. This means that other flags that may
have been set, e.g. SD_JSON_FORMAT_SEQ when --more is set, will be
clobbered.
Fix this by masking SD_JSON_FORMAT_OFF out, and then or'ing the new
flags in.
|
| |
|
|
|
|
|
|
|
|
| |
to a TTY
Let's provide a mechanism to select the number of screen columns for
rebreaking comments in Varlink IDL connected to a TTY, by honouring the
$COLUMNS env var then too. Previously we'd only honour when connected to
a TTY, but it's also useful otherwise for rebreaking ridiculously long
comments, hence honour it in this case too.
|
| | |
|
| | |
|
| |
|
|
| |
Follow-up for 39ce86d19c7c3ac46b4afb546879ca8dcad1bdb2
|
| |
|
|
| |
Fixes: #33772
|
| |
|
|
|
|
|
|
| |
method/interface names are specified
Inspired by #34098 → let's make it easier for users to understand and
correct the mistakes they made: let's early refuse invalid
interface/method names.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It's time. sd-json was already done earlier in this cycle, let's now
make sd-varlink public too.
This is mostly just a search/replace job of epical proportions.
I left some functions internal (mostly IDL handling), and I turned some
static inline calls into regular calls.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
successes
This is generally useful, but in some cases particularly: when
implementing enumeration calls that use the "more" flag to return
multiple replies then for the first reply we need to return an error in
case the list of objects to enumerate is empty, usually so form of
"NoSuchXYZ" error. In many cases this shouldn't really be treated as
error, as an empty list probably more than not is as valid as a list
with one, two or more entries.
|
| | |
|
| |\
| |
| | |
strv: introduce strv_sort_uniq()
|
| | | |
|
| |/ |
|
| |\
| |
| | |
varlinkctl: add --quiet/-q switch for suppressing method call reply output
|
| | |
| |
| |
| |
| |
| |
| | |
empty parameter list
It makes it a bit easier to use "varlinkctl call", since you can just
hit ^D to call a function without params, instead of spelling out {}.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When calling a method and the user hasn't provided any method call
parameters on the command line we expect them on stdin instead. This
might be confusing for people using varlinkctl for the first time, since
omitting the parameters will just throw you at a blinking cursor.
Let's be a bit more helpful, and show a friendly message when we are
connected to a TTY (i.e. run interactively).
|
| | | |
|
| |/
|
|
|
|
|
| |
Follow-up for cdf6f34a2fd1448c5d1b75f4717c57b057dd51b2
We already have other fputs()-like helpers in fileio rather than
io-util. While at it, switch the order of params.
|
| |
|
|
|
|
|
|
|
|
| |
For putting together "varlinkctl call" command lines it's useful to
quickly enumerate all methods implemented by a service. Hence, let's add
a new "list-methods" which uses the introspection data of a service to
quickly list methods.
This is implemented as a special flavour of the "introspect" logic,
and just suppresses all output except for the method names.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
than one
let's make it easier to use the introspection functionality of
"varlinkctl": if no interface name is shown, display the introspection
data of all available interfaces. Moreover, allow that multiple
interfaces can be listed, in which case we enumerate them all.
This relieves the user from having to list interfaces first in order to
find the ones which to introspect.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).
I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).
This is mostly a giant search/replace patch.
|
| |
|
|
|
|
|
|
|
|
|
| |
In varlink.c we generally do not make failing callback functions fatal,
since that should be up to the app. Hence, in case of varlinkctl (where
we want failures to be fatal), make sure to propagate the error back
explicitly.
Before this change a failing call to "varlinkctl --more call …" would result in
a zero exit code. With this it will correctly exit with a non-zero exit
code.
|
| |
|
|
|
|
|
|
|
| |
For the other verbs turning off JSON mode makes sense, but for "call"
not so much, after all the contents of a method call reply is JSON we
couldn't really show any other way.
Hence, when JSON output was not configured otherwise in "call", default
to the same as -j.
|
| |
|
|
|
|
| |
It exposes the varlink_collect() call we internally provide: it collects
all responses of a method call that is issued with the "more" method
call flag. It then returns the result as a single JSON array.
|
| |
|
|
|
|
| |
As it turns out we do this in a similar way at various times (and
sometimes incorrectly), hence add a common implementation to share the
code and fix the incorrect behaviour.
|
| |
|
|
|
|
|
|
| |
The parameter returns the flags field of the reply message. This is only
relevant in very few cases, hence drop it from the call, but keep it in
a more generic varlink_call_full() call for those who need it.
Do something similar for varlink_callb().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
varlink_dispatch() is a simple wrapper around json_dispatch() that
returns clean, standards-compliant InvalidParameter error back to
clients, if the specified JSON cannot be parsed properly.
For this json_dispatch() is extended to return the offending field's
name. Because it already has quite a few parameters, I then renamed
json_dispatch() to json_dispatch_full() and made json_dispatch() a
wrapper around it that passes the new argument as NULL. While doing so I
figured we should also get rid of the bad= argument in the short
wrapper, since it's only used in the OCI code.
To simplify the OCI code this adds a second wrapper oci_dispatch()
around json_dispatch_full(), that fills in bad= the way we want.
Net result: instead of one json_dispatch() call there are now:
1. json_dispatch_full() for the fully feature mother of all dispathers.
2. json_dispatch() for the simpler version that you want to use most of
the time.
3. varlink_dispatch() that generates nice Varlink errors
4. oci_dispatch() that does the OCI specific error handling
And that's all there is.
|
| | |
|
| |
|
