bzr-mac team mailing list archive

[Jean-Francois Roy <bahamut@xxxxxxxxxxxx>]

On Feb 5, 2010, at 09:26, Neil Martinsen-Burrell wrote:

> On 2010-02-05 11:14 , Russel Winder wrote:
>> I appreciate that this isn't so much a dark corner, more inside the
>> event horizon of a black hole, but . . . 
>> 
>> If I connect to a Mac OS X machine using SSH over Ethernet, I get a
>> terminal as per expectation.  (I should add that normally I am logged
>> onto the console of the machine even though I don't actually use the
>> console because various things to do with using Java on a Mac OS X
>> machine require you to be logged onto the console before connecting via
>> SSH over Ethernet.)
>> 
>> If I do:
>> 
>> 	bzr log
>> 
>> then the output appears on the terminal.  If I do:
>> 
>> 	bzr explorer .
>> 
>> then a window appears on the console, and nothing appears on the
>> terminal, it just appears to have hung.  Both of these surprised me.  A
>> lot.
> 
> This is the way that SSH connections to Mac OS X machines work.  If you
> are logged in on the console and you start a graphical application in an
> SSH session, that application can make its windows on the console.  No
> output to the terminal is the ordinary behavior of the ``bzr explorer``
> command and nothing different is happening here.
> 
> If you want to surprise yourself more, run a terminal on the console,
> SSH to localhost and do "open -a TextEdit.app".  Bug or feature, it's up
> to you, but this is the way OS X works.
> 
> -Neil

Mac OS X has a more complex notion of user sessions. In any given system, a particular user has one global system sessions and any number of active security sessions underneath his or her system session. A user's system session may be active at launch if, for example, the user has a LaunchDaemon to run some service on behalf of the user (for example, a iTunes music sharing service).

When you log in through the UI or SSH, a new security session is created. Processes inside a given security session cannot communicate with processes in other security sessions (no horizontal communication), but can communicate with processes below them (e.g. in the user's global system session or with the root session).

When a user logs in through the window server, his or her system session becomes the owner of the console (e.g. the UI). This is what allows a command line session created by Terminal or an SSH connection (which would be a different security session than the security session created by login-in from the UI) to open UI programs on behalf of the user -- the user's associated system session, which all of his or her security session can talk to, owns the console. It would be highly surprising if I couldn't launch a UI application from the Terminal, say from GDB to debug it.

If you log out from the UI or use Fast User Switching, you'll get an error trying to launch any UI application, although it won't affect any services or other security sessions running on your behalf.

So this behavior if definitely by design :)

Jean-Francois