Jump to content

How to tell if script is running in Alfred


Recommended Posts

An environment variable is only accessible inside it’s environment. For example, if you set an environment variable inside a Terminal session, it’ll only be available inside that session. The same applies to Alfred’s environment variables. What you’re looking for is a system-wide (or global) environment variable.

 

Alfred itself doesn’t do it, so the solution is for you to tell your script to do it. But I’d consider another option. Instead of setting a global environmental variable, create a temporary file with a specific name. Then check for the existence of said file (and remove it when you no longer need it).

Link to post
20 hours ago, Gary King said:

Is there an environment variable that Alfred sets, that indicates that it's running a script in a workflow? I'd like to use this variable to set the script's environment to "production" when it's set, and to "development" when not.

 

If you just need to check whether your script is running in Alfred or not, check for the existence of one of the environment variables Alfred sets, e.g. alfred_version. If it's set, your script is running in Alfred.

Link to post
19 hours ago, deanishe said:

 

If you just need to check whether your script is running in Alfred or not, check for the existence of one of the environment variables Alfred sets, e.g. alfred_version. If it's set, your script is running in Alfred.

Thanks, but this variable also exists when I run the script outside of Alfred. Looking at `env` in Bash, I actually have a ton of Alfred variables already set there.

 

I found a few `alfred_` keys that exist only in the workflow though, so I'll use one of those other ones.

Edited by Gary King
Link to post
29 minutes ago, Gary King said:

this variable also exists when I run the script outside of Alfred. 

 

Then you’ve screwed up your shell environment. You should *not* be setting Alfred’s variables in your normal bash environment.

 

Only if you need to run a workflow script that will otherwise fail outside of Alfred, i.e. you’re developing a workflow. For my part, I use the autoenv plugin for zsh to ensure such variables

are only set when I’m in a workflow’s repo and are immediately unset when I leave that directory.

Link to post
1 hour ago, deanishe said:

 

Then you’ve screwed up your shell environment. You should *not* be setting Alfred’s variables in your normal bash environment.

 

Only if you need to run a workflow script that will otherwise fail outside of Alfred, i.e. you’re developing a workflow. For my part, I use the autoenv plugin for zsh to ensure such variables

are only set when I’m in a workflow’s repo and are immediately unset when I leave that directory.

I'm not sure how the Alfred env vars ended up in my Bash env. 

 

I have a workflow called "Finder" on my Mac, which contains several File Filters that I use to look for specific file types in different folders. That's the one whose Alfred env vars appear in my Bash, such as "alfred_workflow_uid" and "alfred_workflow_name". "alfred_workflow_bundleid" is not set though. 

 

I don't know where these vars are being set. I looked in the usual places like ~/.bash_profile, ~/.bashrc, etc. but couldn't find them.

 

---

 

Upon further inspection, I think I know why the Alfred env vars appear in Bash. What happens is that I have an Alfred workflow that opens iTerm, and therefore when I open iTerm with this workflow, the env vars are set. If I open iTerm through the Dock, then no Alfred env vars are set. So it seems to simply be working normally.

Edited by Gary King
Link to post
8 minutes ago, Gary King said:

What happens is that I have an Alfred workflow that opens iTerm

 

Oh yeah, that would do it. You might want to consider using Alfred's (macOS's) built-in method for opening apps—or using env -i—so as not to inherit the workflow's environment.

 

This is something that annoys me about macOS. I wish your entire user session were bootstrapped from a shell, like on Linux. Very annoying for developers.

Link to post
7 minutes ago, deanishe said:

 

Oh yeah, that would do it. You might want to consider using Alfred's (macOS's) built-in method for opening apps—or using env -i—so as not to inherit the workflow's environment.

 

This is something that annoys me about macOS. I wish your entire user session were bootstrapped from a shell, like on Linux. Very annoying for developers.

Is there any problems with having the Alfred env vars exist in my shell? Or it just leads to possible "confusion", such as if my script is trying to read an Alfred env var, then the value would possibly be incorrect? 

 

The reason I open apps like Terminal via a workflow using system commands (os.system in Python) rather than Alfred's method, is because I usually also need to pass args to the commands. And depending on the keywords used, a different app would be opened, etc. 

Edited by Gary King
Link to post
32 minutes ago, Gary King said:

Is there any problems with having the Alfred env vars exist in my shell?

 

You've just kinda run into one… The bottom line is that those alfred_* variables should only exist in a (test) workflow environment. In part because some are specific to one workflow, and also because checking for the existence of one of the variables is the obvious (and only practical) way for code to tell if it's running in an Alfred workflow or not.

 

That may never have been a problem until today, but it is a misconfiguration waiting to cause an issue.

 

37 minutes ago, Gary King said:

I usually also need to pass args to the commands.

 

The open command can pass arguments to a command. It's semantics are the same as the way Alfred opens things, too (i.e. via launchd).

Link to post
5 hours ago, Martin Packer said:

I’m wondering if there’s something else you could do that would only work in an Alfred environment - such as getting the Alfred version.

 

Dude, that's literally what I just described. Setting an environment variable is the standard way to tell a program it's being run from another program. That or a command-line option.

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...