After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734576 - gdbus tool: does not identify itself in its error messages
gdbus tool: does not identify itself in its error messages
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gdbus
2.40.x
Other Linux
: Normal minor
: ---
Assigned To: David Zeuthen (not reading bugmail)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-08-10 16:14 UTC by Simon McVittie
Modified: 2018-05-24 16:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Simon McVittie 2014-08-10 16:14:27 UTC
On <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730567>, Vincent Lefevre wrote:

----8<----

It appears that gdbus can output the error message:

  Error: Timeout was reached

so that when it is used in a script, the user cannot know where
this message comes from and is confused. See

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729527

for instance.

When outputting an error message, a utility must always identifies
itself. Here, it should be:

  gdbus: Error: Timeout was reached

or

  gdbus error: Timeout was reached

----8<----

The code causing this appears to be in gio/gdbus-tool.c itself, rather than in the library.
Comment 1 David Zeuthen (not reading bugmail) 2014-08-11 20:36:32 UTC
I don't think it's gdbus(1)'s job to prepend its own name (or for that matter, any program). Why? Because any script or program using gdbus(1) (or for that matter, any program) is perfectly capable of doing this itself - just collect stderr and the exit code. If the exit-code is non-zero, bubble the error up (i.e. print it to stderr or a log file or whatever) optionally prepending "gdbus: " or however you want to identify it.

I'm not doing much GLib work these days so I'll leave it to someone else to close this NOTABUG or weigh in, saying I'm wrong etc. :-)
Comment 2 Vincent Lefevre 2014-08-11 21:30:33 UTC
(In reply to comment #1)
> I don't think it's gdbus(1)'s job to prepend its own name (or for that matter,
> any program). Why? Because any script or program using gdbus(1) (or for that
> matter, any program) is perfectly capable of doing this itself - just collect
> stderr and the exit code. If the exit-code is non-zero, bubble the error up
> (i.e. print it to stderr or a log file or whatever) optionally prepending
> "gdbus: " or however you want to identify it.

While this may be possible here, note that almost all utilities prepend their own name in case of error: cp, mv, rm, ls, stat, diff, find, grep... So, in addition to not being the common behavior, it is not obvious for the developer to guess that. If really there's a problem for gdbus in prepending its own name, then you should document that. In particular, the user must know that it is safe to collect stderr (this is not always the case with all utilities, e.g. because of interactivity or because of possible warnings that one may want to see in real time).
Comment 3 Colin Walters 2014-08-13 02:22:40 UTC
(In reply to comment #2)
 want to identify it.
> 
> While this may be possible here, note that almost all utilities

coreutils certainly does it consistently.  So does systemd.  I'd would agree it's best practice, but you'll find a lot of tools don't.

Similar example:

$ dbus-send --address=unix:foo=blah / m
Failed to open connection to "unix:foo=blah" message bus: Server address of type unix was missing argument path or abstract

^ dbus does not

$ gnome-terminal --xalbfaw
Failed to parse arguments: Unknown option --xalbfaw

^ gnome-terminal does not

$ docker ps
2014/08/12 22:17:15 Get http:///var/run/docker.sock/v1.12/containers/json: dial unix /var/run/docker.sock: permission denied

A bit farther afield, docker actually outputs log messages by default.

Maybe there is a stronger argument for tools commonly used by shell scripts?
Comment 4 GNOME Infrastructure Team 2018-05-24 16:54:12 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME'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.gnome.org/GNOME/glib/issues/913.