GNOME Bugzilla – Bug 688699
Retrieving process ID from Vte.Terminal doesn't work
Last modified: 2013-04-14 21:47:03 UTC
I am using Python 3 with GObject introspection to create a Vte.Terminal widget. Up to date and reliable documentation on this widget is scarce. If one uses the fork_command_full() method to create a child process in the aforementioned terminal widget, how does one then retrieve the child process ID? Version 0.26 of the Vte.Terminal documentation claims there is a 9th parameter to fork_command_full() method which is used to store the child's process ID, but my implementation claims there is no such parameter (it takes 8, not 9 parameters). Strangely, the vte.h header on the same system appears to declare a vte_terminal_fork_command_full with a child_pid parameter. If I generate new Python documentation for the system's implementation via GObject introspection tools, it shows a child_pid parameter as well: $ g-ir-doc-tool --language Python -o ./output_dir /usr/share/gir-1.0/Vte-2.90.gir
* @child_pid: (out) (allow-none) (transfer full): a location to store the child PID, or %NULL and the GIR says <parameter name="child_pid" direction="out" caller-allocates="0" transfer-ownership="full" allow-none="1"> <doc xml:whitespace="preserve">a location to store the child PID, or %NULL</doc> <type name="GLib.Pid" c:type="GPid*"/> </parameter> which looks correct to me. Please specify which exact versions of vte and gobject-introspection you're using.
Hey Christian. My system's Vte-2.90.gir contains the same. ... <parameter name="child_pid" direction="out" caller-allocates="0" transfer-ownership="full" allow-none="1"> <doc xml:whitespace="preserve">a location to store the child PID, or %NULL</doc> <type name="GLib.Pid" c:type="GPid*"/> </parameter> ... It is located at /usr/share/gir-1.0/Vte-2.90.gir, provided by my Ubuntu Precise (amd64) distribution's libvte-2.90-dev package, which claims to be of version 1:0.32.1-0ubuntu1. If that doesn't answer your question, please let me know how I can verify the exact versions of VTE and GObject-Introspection.
Created attachment 233491 [details] Kip's GI metadata for the VTE library.
Out parameters in PyGObject are translated into function return values (they will be part of a tuple if there is more than one). The doc generation needs work to show this, pydoc does attempt to help: In [3]: Vte.Terminal.fork_command_full? Type: function Definition: Vte.Terminal.fork_command_full(*args, **kwargs) Docstring: fork_command_full(self, pty_flags:Vte.PtyFlags, working_directory:str, argv:list, envv:list, spawn_flags:GLib.SpawnFlags, child_setup:GLib.SpawnChildSetupFunc, child_setup_data:void) -> child_pid:int
Hey Simon. The Vte-2.90.gir claims the return value is just a boolean value of whether the call succeeded or not: <return-value transfer-ownership="none"> <doc xml:whitespace="preserve">%TRUE on success, or %FALSE on error with @error filled in</doc> <type name="gboolean" c:type="gboolean"/> </return-value> Do you mean the child PID is suppose to be returned as part of a tuple? e.g. (success, child_pid)
(In reply to comment #5) > Do you mean the child PID is suppose to be returned as part of a tuple? e.g. > (success, child_pid) Yes, if the function normally returns non-void, the return will always be the first item in the tuple and out args will following. Although this points out a potential problem with the pydoc as the function signature should be: ... -> (bool, child_pid:int) Is this what you see in actual usage of the function?