> On May 21, 2015, at 11:09 AM, Carl Hoefs <[email protected]>
> wrote:
>
>
>> On May 21, 2015, at 8:12 AM, Karl Kuehn <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On May 20, 2015, at 3:14 PM, Carl Hoefs <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> From a bash script I launch an app, but I only want this behavior if the
>>> user is locally logged in at the console. If the user has ssh’d into the
>>> machine and is running the bash script, the app launch should not be
>>> attempted (it will fail since the user doesn’t ‘own’ the screen).
>>
>>
>> What is the trigger event for your script? If it is login, then you can
>> just use the launch-agent part of launchd to make this distinction. The
>> `LimitLoadToSessionType` key take “Aqua” and “StandardIO” to differentiate
>> between GUI and non-GUI (e.g.: ssh) sessions. There are also “Background”
>> that apply to all types of logins, and "LoginWindow” that only runs in that
>> context.
>>
>
> The user invokes the script directly (it’s a ‘command’ that resides in
> /opt/local/bin). It processes many large data files and then — if the user is
> local to the machine — displays a graphical analysis of the results onscreen
> by launching an app; otherwise a textual representation is output in the
> user’s shell. So launchctl isn’t involved.
>
> Trying to open an app when the user isn’t logged in at the console produces:
>
> LSOpenURLsWithRole() failed with error -10810
>
> Checking the $SSH env var works, but I was thinking that there might be a
> dedicated method to make this determination, which of course I would prefer
> to use. Apparently, there isn’t, so checking the env var will suffice.
Silly thought: why not just let it fail? This is one of those *nix
traditions: try it and handle the error.
—
Karl Kuehn
[email protected]
_______________________________________________
MacOSX-talk mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/macosx-talk
