On a CI infrastructure, we connect nodes through SSH and launch automated app testing.
So, I'm going to start with a very short answer, then try and give a much longer answer. So, the short answer first:
open /Applications/Pages.app
Great! You should do that!
/Applications/Pages.app/Contents/MacOS/
Yes, you really shouldn't do this.
Long Answer:
Let's start with what this actually does:
open /Applications/Pages.app
Part of our system’s fundamental design is the idea of execution contexts. If you want to learn more about some of the details, the great classic, TN2083: Daemons and Agents, is probably the best entry point. However, summarizing the most relevant details...
First off, for our purposes, there are two relevant execution contexts:
-
The "global" or "system" session. This is running all the time and cannot present any kind of user interface. This is where "daemons" run.
-
"User" or "login" sessions (there can be more than one if multiple users are logged in). Logging in creates a login session, and logging out destroys it. Apps can only "work" in a user session because all of the supporting "infrastructure" that lets an app interact with the screen is actually tied to their user session. This is where "agents" run.
A process "gets" an execution context in one of two ways:
-
It implicitly inherits its execution context from its parent process.
-
Its execution context is explicitly configured by launchd, the special process whose job it is to manage all these sessions.
So, returning to here, what this does:
open /Applications/Pages.app
...is ask (through multiple levels of indirection) launchd to launch a process into the "current" user session.
Note that, strictly speaking, this is the only way that the system ACTUALLY supports "apps" launching. The reason this works:
/Applications/Pages.app/Contents/MacOS/Pages
# ==> Work as expected if launched from a local terminal
...is semi-accidental. That is, Terminal.app is an app running in the user session, which then passed that execution context over to the shell, which then passed it over to the app that you then launched. Strictly speaking, this process isn't really "supposed" to work, but in practice, it basically works.
All of which then leads to here:
ssh <YOUR_MAC_TAHOE>
/Applications/Pages.app/Contents/MacOS/Pages
# ==> Navigate until you can enter text; no keyboard input is working
# ==> App does not show up on the app bar
Theoretically, this should NEVER have worked. TN2104 actually describes why this should NOT work:
"A common question we get in DTS is "How can I launch a GUI application from my daemon?" The answer is that you can't. This is a direct consequence of Mac OS X's layered architecture: a daemon can't launch a GUI application because the daemon is running in the wrong context. Even if it could choose which context to run the GUI application in, which would it choose? And what happens if the computer is sitting at the login window, which means there are no valid GUI contexts?"
Your ssh session is connecting through sshd (a daemon in the global session), which means it has no connection to the WindowServer and no ability to present UI. TN2104 then describes the "loophole" that allows open to work, but that won't work for the direct launch case.
Do I miss a system configuration to restore the ability to launch apps from SSH ?
There isn't any setting for this because this isn't something that the system is really "trying" to make work. The fact that it works at all is primarily due to a historical accident, not an explicit design goal. I'm not sure what system version you were previously doing this on, but on most system versions, it hasn't actually worked.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
