Launch Application via Outset

[aljewaryk]

Hey @chilcote,

We love using outset at @OhioUniversityScripps but we have a need for launching an application on every login. If we did a pull request with appropriate changes, will you accept?

If so, @rickychilcott and I can do it next week.

Thank you Kahtan Al Jewary

[chilcote]

Wouldn't it be easier to put in a script?

[rickychilcott]

Yeah we could. We just thought that maybe symlinking to the app could be an interesting approach.

On Fri, Sep 25, 2015 at 2:47 PM, Joseph Chilcote notifications@github.com wrote: Wouldn't it be easier to put in a script?

— Reply to this email directly or view it on GitHub [https://github.com/chilcote/outset/issues/25#issuecomment-143319395] .[https://github.com/notifications/beacon/AAbNP1qiKpH7jR3E6qK9ni29Y-0OzFadks5o1Y5CgaJpZM4GEB_a.gif]

[chilcote]

(editing this to sound less grumpy)

How would the symlink get there? Via a firstboot script?

I can see this going wrong in a bunch of ways. What if the app moves, and the symlink isn't updated? What happens when the app is updated to a new version, will the symlink still work?

I'd think throwing some osascript lines in there to add apps to the login items would be nice solution, maybe? Or even an osascript -e open /Applications/Safari.app

[rickychilcott]

Haha. Less grumpy is good!

On a postinstall script of an application install, we would throw the symplink in. Moving an app is indeed a consideration, however script or applescript solutions would fall down the same way.

I do realize we could easily just write a script to /usr/local/outset/every-login/launch_safari.sh on postinstall (setting the correct perms, etc.).

#!/bin/sh

open /Applications/Safari.app

However, it seems a bit clunky. We thought maybe a symlink to the app would be similar to the firstboot package installs.

[erikng]

I don't understand the use case either. What exactly are you trying to do?

Sent from my iPhone

On Sep 25, 2015, at 2:23 PM, Ricky Chilcott notifications@github.com wrote:

Haha. Less grumpy is good!

On a postinstall script of an application install, we would throw the symplink in. Moving an app is indeed a consideration, however script or applescript solutions would fall down the same way.

I do realize we could easily just write a script to /usr/local/outset/every-login/launch_safari.sh on postinstall (setting the correct perms, etc.).

!/bin/sh

open /Applications/Safari.app However, it seems a bit clunky. We thought maybe a symlink to the app would be similar to the firstboot package installs.

— Reply to this email directly or view it on GitHub.

[rickychilcott]

This specific need is for our upcoming deployment of https://github.com/ygini/Hello-IT to our labs, classrooms, and faculty. We'll have to deploy several script files, a plist, and the app and can certainly deploy a small script to the outset directory to launch that app as well for this particular project. That said, a symlink might be a clever approach if all I need to do is open an app at user login.

I was trying to solve this problem for other folks too. Again, it's not a big deal if we don't implement the feature. I just wanted to ask before we wrote the PR.

[erikng]

Sounds like Yoann/you need a simple launch agent to resolve the launching issue.

He already supports profiles, so you can deploy the profile outside of outset. The application itself should probably be deployed through Casper/munki.

Obviously chiclote can decide whether or not to do something like this, but it sounds like your tackling this with the wrong toolset.

On Sep 25, 2015, at 3:14 PM, Ricky Chilcott notifications@github.com wrote:

This specific need is for our upcoming deployment of https://github.com/ygini/Hello-IT to our labs, classrooms, and faculty. We'll have to deploy several script files, a plist, and the app and can certainly deploy a small script to the outset directory to launch that app as well for this particular project. That said, a symlink might be a clever approach if all I need to do is open an app at user login.

I was trying to solve this problem for other folks too. Again, it's not a big deal if we don't implement the feature. I just wanted to ask before we wrote the PR.

— Reply to this email directly or view it on GitHub.

[chilcote]

Apple has support for this (Login Items). I've not looked at Hello-IT, but why is it any different than any other application that gets launched via Login Items or LaunchAgent? Unless I'm missing something obvious, it seems that this is the wrong tool for the job?

[arubdesu]

https://github.com/pudquick/pyLoginItems Does that address it, delivered by outset or what-have-you?

[chilcote]

Another thought... what happens when a user quits the menu bar app, or it crashes? It won't launch again until someone logs out and back in? This all can be solved with a LaunchAgent I would think.

[chilcote]

pyLoginItems looks handy too.

[rickychilcott]

After some further pondering, you all convinced me. I think a standalone LaunchAgent is the winner because it provides the re-launch capability if the app crashes or the user force quits it. The following plist will do the trick for us. And I'll do a PR for the Hello IT project.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>KeepAlive</key>
    <true/>
    <key>Label</key>
    <string>com.github.ygini.hello-it</string>
    <key>ProgramArguments</key>
    <array>
      <string>/Applications/Hello IT.app/Contents/MacOS/Hello IT</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

I will say, we try not to have lots of LaunchAgents as to speed up login and using outset has been great for that. Adding more LaunchAgents, in my opinion, without true need, feels like a system administration smell. Less is more in this case. Managing the users login items seems like a loosing proposition too -- they can easily delete them.

For now, we can close this issue, but thanks for the debate!

[chilcote]

Keeping launchagents to a minimum was a goal of outset. However, I still think it will be a good thing if Hello-IT has a supported method of managing its app launching, similar to something like TextExpander, etc.

That being said, I think adding support for opening arbitrary files might sneak into outset at some point in the future. Thanks for the idea.

[arubdesu]

I think there's always room for simple-ish(subjective, I know), common-case tasks, but the ones that spring to mind are shortcuts to e.g. fileshares on the desktop, or items in the Dock. But that can be fodder for another issue/request.

[chilcote]

Try out the latest commits. Instead of relying on symlinks, I added an array in the config plist for "load_apps" and "load_files".

What you can do is run outset --add-app-every or outset --add-app-once and either give it the name of an App or a full path. Outset will process those arrays at login and launch the app in the appropriate context. You can then remove the apps with outset --remove-app.

For files, it's a bit different. I didn't want the user to be opening files owned by root, so what you do is package your files to go into /usr/local/outset/share/foo.txt and then run outset --add-file-once or outset --add-file-every and at login it will copy the file from the share directory to the user's Desktop and open it there, and will update the run_once plist.

Lemme know what you think.

[chilcote]

OK I take it back... I hate everything I did here, and I rolled back to before these commits.

As @vmiller put it in Slack: "outset is a tool to run scripts, it doesn't need to be extended to the point of doing the work of the scripts"

I agree with this sentiment. I think that instead of trying to solve things that can be scripted, I'd rather see a community open up around sharing scripts.