Question about isatty/read usage in dbus-launch

[Havoc Pennington]

Hi,

The reason I haven't come out and said "let's make changes a, b, and c" 
is that they will cause some churn/disruption and there should be a 
well-thought-through master plan so we don't go in circles changing it 
back and forth.

There are also some larger-scope partly-related changes:
http://lists.freedesktop.org/archives/dbus/2006-October/005906.html

(Those last proposed changes at least make dbus-launch pretty 
configurable in what it does; perhaps in that spirit, if we split 
--exit-with-session into --exit-with-x-session / --exit-with-tty-session 
then that would be a plausible solution to the problem at hand, though 
it still wouldn't _fix_ --exit-with-tty-session to work right)

We could have an --exit-with-launched-program also though I do think 
it's a little silly; it's called "inter-process communication" because 
there are at least two processes ;-) but it could be useful for 
debugging and such.

If you do something like "dbus-launch firefox" then as dbus is more 
heavily used, effectively what will happen is that firefox gets its 
whole own private desktop session, where all kinds of services might get 
launched. If you were already logged in, you'd get second copies of 
everything vs. your main desktop session.

An example of what could go wrong; we might have an "open a single 
instance app" service on the bus, so say I do "dbus-launch firefox" and 
it uses this service to open a document in OpenOffice, then I close 
firefox, I am *not* expecting my OpenOffice to exit. But that's what 
would happen with --exit-with-launched-program.

(Remember that dbus-daemon defines the session lifecycle, normal apps 
are supposed to exit when disconnected from it and assume anything 
sharing their session is on the same session bus.)

Anyhow... more reasonable uses of dbus-launch might include:
  - running one daemon per X display/session
  - one per ssh or console session
  - it's used internally by libdbus to do the autolaunch
    work (though whenever autolaunch happens, your setup is
    incorrect or at least suboptimal)
  - doing a "dbus-launch bash" in order to get a debugging
    session with everything you run in the bash sharing a
    daemon
  - probably some other debugging-type usages

Given the use cases of an X session or an ssh session, offhand it seems 
reasonable to split up --exit-with-session into --exit-with-x-session / 
--exit-with-tty-session (with current --exit-with-session equivalent to 
specifying both flags).

Regarding the double fork/exec, it makes sense to me in the case of 
starting the bus for a session; I don't think exiting when the child 
exits is right in that case, so we don't care about the child's return 
code or exit status and we can just reap it.

When doing a debug thing like "dbus-launch bash" then 
--exit-with-launched-program (presumably implemented by not reaping the 
child right away) sounds handy.

It might be nice to write up a short list of use-cases, then a patch for 
the man page documenting new options we should have, including the 
various --exit-with plus those discussed here or improvements on them:
http://lists.freedesktop.org/archives/dbus/2006-October/005906.html

Then we'll have a sort of "dbus-launch roadmap" in the form of the use 
cases plus man page changes. It'd also be nice to figure out the bug Ray 
posted,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214649

Of course, it's pretty academic unless someone has time to work on 
sorting this out...

Havoc