How to tell if script is running in Alfred

[Gary King]

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.

[vitor]

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

[deanishe]

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.

[Gary King]

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 May 11, 2018 by Gary King

[deanishe]

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.

[Gary King]

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 May 11, 2018 by Gary King

[deanishe]

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.

[Gary King]

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 May 11, 2018 by Gary King

[deanishe]

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

[Martin Packer]

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.

[deanishe]

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.

[Martin Packer]

Sorry, I didn’t see yours before I posted mine.