> On May 21, 2015, at 11:24 AM, Carl Hoefs <newsli...@autonomy.caltech.edu>
> wrote:
>
>>
>> On May 21, 2015, at 11:19 AM, Karl Kuehn <kuehn.k...@gmail.com
>> <mailto:kuehn.k...@gmail.com>> wrote:
>>
>>>
>>> On May 21, 2015, at 11:09 AM, Carl Hoefs <newsli...@autonomy.caltech.edu
>>> <mailto:newsli...@autonomy.caltech.edu>> wrote:
>>>
>>>
>>>> On May 21, 2015, at 8:12 AM, Karl Kuehn <kuehn.k...@gmail.com
>>>> <mailto:kuehn.k...@gmail.com>> wrote:
>>>>
>>>>
>>>>> On May 20, 2015, at 3:14 PM, Carl Hoefs <newsli...@autonomy.caltech.edu
>>>>> <mailto:newsli...@autonomy.caltech.edu>> 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
At this point I do almost all of my scripting in Python, and there it
would be trivial to capture the error output, and use it to decide to display
things on STDOUT. It would be a little harder with bash, and probably involve a
temporary file, but it would still be possible. Doing this would mean you never
have to depend on tricky environment things: it either works on the GUI, or it
gracefully falls back to the tty side.
—
Karl Kuehn
kuehn.k...@gmail.com
_______________________________________________
MacOSX-talk mailing list
MacOSX-talk@omnigroup.com
http://www.omnigroup.com/mailman/listinfo/macosx-talk
