Automator use current directory location

Question

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 ?

Answer 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.

Answer 2

In Automator, create a workflow with Run Applescript first:

on run {input, parameters}
    set p to path to me
    return p
end run

.. and then chain it to a Run Shell Script that has Pass input: as arguments:

APP_PATH=$1
cd "$APP_PATH/Contents"
...

Save it as an Application.

Here's a screenshot where I use this to start SQLWorkbench/J:

(SQLWOrkbench/J's zip file is unzipped into the resulting app's Contents folder)

Answer 3

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”.