> On May 21, 2015, at 11:34 AM, Karl Kuehn <[email protected]> wrote: > > >> On May 21, 2015, at 11:24 AM, Carl Hoefs <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On May 21, 2015, at 11:19 AM, Karl Kuehn <[email protected] >>> <mailto:[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 > > > 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. >
Agreed! In hindsight, bash was a poor choice, considering the crazy syntax required for even the simplest things. It started out as a basic script, but became more and more complex. Python would have been a much better choice. Next time! -Carl
_______________________________________________ MacOSX-talk mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-talk
