Bug 105380

Created attachment 137857 [details] [review]
Fix dbus-send not returning an error exit code in case an error occured and --print-reply is not set

This is important to detect issues if dbus-send is used in shell scripts.

(In reply to Ralf Habacker from comment #2)
> This is important to detect issues if dbus-send is used in shell scripts.

Issue: shell script contains dbus-send. Solution: don't? :-)

More seriously, there are almost certainly shell scripts that rely on dbus-send's current behaviour, however stupid that behaviour is.

Comment on attachment 137857 [details] [review]
Fix dbus-send not returning an error exit code in case an error occured and --print-reply is not set

Review of attachment 137857 [details] [review]:
-----------------------------------------------------------------

This is an incompatible change to dbus-send's behaviour. Previously, it could be used in two modes:

* no special options: send message (method call or signal), don't wait (analogous to dbus_connection_send())
* --print-reply: send message, wait (makes no sense for signals), process reply (analogous to dbus_connection_send_with_reply_and_block())

This change makes the first mode impossible. In particular, if we send a signal rather than a method call, we are not going to get a reply, so we'd just block until the timeout and then fail every time.

Making --print-reply the default (at least for method calls) would have been better, but we're about 15 years too late to design the dbus-send CLI, and I don't think it's a good idea to be changing it incompatibly now.

I think "gdbus call" is a better CLI for method calls (it's missing a --no-wait option, but that's quite a rare thing to want in practice), and "gdbus emit" is a better CLI for signals. In particular, the design of the gdbus(1) CLI is in terms of operations that make sense in the high-level model of D-Bus that we encourage people to think in, whereas the design of dbus-send is down at the level of message-passing.

One better solution than this would be to change the man page to say something like this:

"""
To call a method, always use --print-reply, unless you are deliberately not waiting to see whether the method succeeded. --print-reply is not the default for historical reasons, but it should have been.

To emit a signal, use --type=signal and do not use --print-reply.
"""

Perhaps another better solution would be "dbus-call" and "dbus-emit" tools that closely resemble dbus-send but with more sensible defaults - but "gdbus call" and "gdbus emit" are basically already those tools, so perhaps implementing them would be a waste of time.

::: doc/dbus-send.1.xml.in
@@ +156,5 @@
> +  <title>EXIT STATUS</title>
> +  <para>
> +    <command>dbus-send</command>
> +    exits with status 0 on success and status 1 in case of errors.
> +    In the error case a related message will be printed to stderr.</para>

This is still useful documentation without the behaviour change, but if --print-reply isn't used, "the service sent back an error reply" is not an error that is (or can be) detected. It could perhaps become something like this:

"""
If the --print-reply option is used, dbus-send exits with status 0 after a successful reply, or a nonzero status otherwise (if connecting to the bus fails, if it receives an error reply, or if the timeout is reached).

If the --print-reply option is not used, dbus-send exits with status 0 when the message has been successfully sent, or a nonzero status otherwise (for example if connecting to the bus fails). In this case dbus-send does not wait for the message to be processed, so it cannot report an error reply.

On failure, a diagnostic message is printed to stderr.
"""

Another possibility would be a new --wait or --wait-reply option that has all the side-effects of --print-reply except actually printing the message, but that's essentially equivalent to 

    dbus-send --print-reply ... >/dev/null

(or >NUL: or however you spell that on Windows) in any case.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/199.