> On May 21, 2015, at 11:19 AM, Karl Kuehn <[email protected]> wrote:
> 
>> 
>> On May 21, 2015, at 11:09 AM, Carl Hoefs <[email protected] 
>> <mailto:[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.

It’s a requirement. I have to display a graphical interpretation of the 
results. If not possible (i.e., remote user), generate a statistical table 
inline with ascii text. The error message doesn’t inspire user confidence, so 
being able to determine which one to do is a Good Thing. 
-Carl

_______________________________________________
MacOSX-talk mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/macosx-talk

Reply via email to