6

my goal is to use Automator to open an application with arguments

open ./MyApp.app -arguments

via running a shareable Buddy.app with Myapp.app (the Automator/workflow). both apps should be shareable together with anyone so they run straight off.

the simplest way to do so, seems to be to run the Buddy.app from within the same folder as MyApp.app. then i can move the Buddy.app with MyApp.app anywhere, and they will still work together

to set up the relative file locations in bash script,

open "$(pwd)"/myapp.app -arguments

only problem is that Automator uses the home directory instead of the application directory. ie pwd is the home directory, and not the actual file location.

in Automator the output from

echo $(pwd)

is my home directory, /Users/User

so the question is, how to get Automator (Buddy.app) to detect the current folder location and run MyApp.app ?

  • 1
    As of macOS 10.12, Automator.app is always located in /Applications and protected by SIP. You can verify this by running grep Automator /System/Library/Sandbox/rootless.conf, or ls -ldAO@ /Applications/Automator.app. So why not simply hard-code /Applications? – Synoli Apr 4 '17 at 11:03
  • sorry, that is not what i wish to achieve. i realise the ambiguity in my initial post and have changed it for hopeful clarity. i want to run myapp.app -arguments from anywhere by simply opening the automator.app/workflow – watermelon Apr 5 '17 at 11:45
  • If I understand the question correctly your workflow would require to copy myapp.app (or at least an alias) to the current path. Usually this is done the other way round: the current path (of e.g. a file/folder) is passed to the app as one argument. pwd or ls won't be copied to $pwd to get the current working directory or a content listing but remain in /bin! – klanomath Apr 5 '17 at 12:47
  • @watermelon Thanks for clarifying and editing your question; though I feel we still need more information to understand your requirements. It would help if you edited your question once again and provide a self-contained example. See my next comment for what my own interpretation of your requirements so far is. I might be completely wrong, and perhaps I grossly misunderstand your requirement; however if that’s the case, I would recommend that you provide a short, self-contained example for the sake of clarity. – Synoli Apr 5 '17 at 15:04
  • 1
    My interpretation: you start out with a directory ~/foo and an app ~/foo/MyApp.app. Your goal is to have an Automator workflow to act as a buddy to MyApp.app, and lives in the same directory as MyApp.app at all times. You want to be able to move MyApp.app at your discretion, into whatever folder you like, for example ~/baras long as the buddy workflow travels along with it. Lastly, you want to be able to launch the buddy workflow from any location, for example from the Finder, or using open ~/bar/MyWorkflow.workflow while you’re inside /tmp/meow. Correct? – Synoli Apr 5 '17 at 15:08
1

Have your workflow figure out its own path (more robust)

This works as long as your Automator workflow lives in the same directory as MyApp.app; you can create copies of either the workflow or the app at your discretion and reuse those copies wherever you want; nothing needs to be unique.

Steps

These are the steps to automate launching MyApp.app:

  1. Open the workflow in Automator.

  2. Add a Run AppleScript action. Remove all the boilerplate code inside and replace it with the following lines:

    set AppleScript's text item delimiters to ":"
    set appPath to (text items 1 through -3 of (path to me as text) & {"MyApp.app"} as text)
    tell application "Finder" to open file appPath
    
  3. Save the Automator workflow in the same folder as MyApp.app.

  4. Run the Automator workflow; it should launch MyApp.app.

Explanation

set AppleScript's text item delimiters to ":"

This means “Watch out, I’m going to split a string soon; and I want you to use the : character as the split boundaries.”

path to me as text

This instructs the workflow to figure out the path to itself; path components are delimited by a colon (:), which is a remnant of Classic Mac OS.

text items 1 through -3 of […] & {"MyApp.app"}

This cuts off the last part of the path, and appends MyApp.app to the path.

[…] as text

This pieces the path back together (again with : as a delimiter).

tell application "Finder" to open file appPath

Lastly, this final line causes MyApp.app to launch.

  • this works fine with no arguments. however i still need to pass arguments when opening. – watermelon Apr 19 '17 at 2:34
0

Use the target app’s bundle identifier (more flexible)

Do you plan to keep only one single copy of MyApp.app on the entire system?

If so, you can take advantage of MyApp.app’s bundle identifier, and have Launch Services figure out all the nitty-gritty details for you.

This solution is rather flexible; it has the benefit that you can put your Automator workflow wherever you want – it does not have to be in the same location as MyApp.app, nor in any fixed location relative to it.

Steps

These are the steps you want to take:

  1. Open Terminal.app and run the following command:

    osascript -e 'id of app "'"$(mdfind MyApp.app)"'"'
    
  2. The previous step should have printed out one single line as a result. Note what that line says (e. g. com.example.MyApp).

  3. Open your workflow in Automator.

  4. Add a Run Shell Script action with the content:

    open -b com.example.MyApp
    
  5. Save the Automator workflow in any folder at your discretion – no need to put it in a fixed location relative to MyApp.app.

  6. Run the Automator workflow; it should launch MyApp.app.

Explanation

Launch services

This solution takes advantage of a part of macOS called Launch Services, which maintain a system-wide database of apps and their properties:

Whenever a new application becomes known to the system (such as when the user drags it from an installation disk into the Applications folder), the application is registered with Launch Services, which copies the needed information about the application into its database. Launch Services can then use this information to determine the preferred application for opening a given document file or URL.

The plan

The piece of information we’re interested in is the bundle identifier, or bundle ID.

An App developer typically assigns to each of her or his apps a (hopefully) globally unique bundle ID. We can take advantage of this uniqueness if and only if there is no more then one single app with the same bundle ID on our whole system – and only one single copy of that app. No duplicates.

Figuring out the path

The command

mdfind MyApp.app

is just a fancy way to run a Spotlight search as a one-time shortcut in order to figure out the app’s path as of right now. We need the path only once in order to extract the app’s bundle identifier.

Spotlight will (hopefully) return with something like this:

/Users/watermelon/foo/MyApp.app

Extracting CFBundleIdentifier

Wrapping the app’s current path in the following AppleScript command:

id of app "/Users/watermelon/foo/MyApp.app"

is simply a convenient way to **extract the CFBundleIdentifier ** from the MyApp.app bundle.

(You could have also looked up the bundle ID manually by right-clicking the app in Finder, choosing Show Package content, navigating to the Contents subfolder and opening Contents/Info.plist in TextEdit, search for the key that says CFBundleIdentifier and find its String value one line further down. I think this is tedious, therefore I always prefer to use the AppleScript/mdfind snippet.)

Launching an app by bundle ID

Finally, let’s have a look at the command you’re actually going to use in your Automator workflow:

open -b com.example.MyApp

This command is just a technical way of saying “Hey macOS, you’re good friends with launchd, right? Can you have it launch this app for me? Oh btw, I never bothered to look up the full path to it. What I do know though is its CFBundleIdentifier, which is com.example.MyApp; just go ask Launch Services and they will figure out the path”.

  • thanks for both replies. i've amended my question to mention that both apps need to be shareable and useable immediatley upon sharing, so this answer is unfortunately not appropriate. – watermelon Apr 19 '17 at 2:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .