Some new alfred_ script environment variables coming in Alfred 2.4

[Andrew]

Hey all,

 

Just a quick heads up that I've added some useful alfred_ environment variables into the 2.4 b277 pre-release build which may help with some aspects of your workflows. Here is what you can expect:

 

    "alfred_preferences" = "/Users/Crayons/Dropbox/Alfred/Alfred.alfredpreferences";

    "alfred_preferences_localhash" = adbd4f66bc3ae8493832af61a41ee609b20d8705;

    "alfred_theme" = "alfred.theme.yosemite";

    "alfred_theme_background" = "rgba(255,255,255,0.98)";

    "alfred_version" = "2.4";

    "alfred_version_build" = 276;

    "alfred_workflow_uid" = "user.workflow.FDC54875-6670-45CC-9D6B-1879F9257FBB";

 

The only one I feel needs explanation is alfred_preferences_localhash - for Alfred 2.4, non synced prefs are moving out of the standard OS X preferences as there is a Yosemite issue with prefs inheritance between Alfred Preferences.app and Alfred 2.app. Any local (mac specific) preferences are now stored within Alfred.alfredpreferences under .../preferences/local/[alfred_preferences_localhash]/ instead and use Alfred's own preferences framework.

 

Let me know if these are useful for you

 

Cheers,

Andrew

[rice.shawn]

Amazingly useful.

 

For testing purposes, is there anyway to load these outside of a workflow with maybe an info.plist? I assume the answer is no: not possible.

[Carlos-Sz]

I think you forgot to list one:

 

"alfred_theme_subtext” = 0 or 1 or 2 or 3

 

Please!

[deanishe]

This is totally awesome.

 

Does alfred_theme_iconstyle mean what I think it means, or is this a bug? The values seem to contradict those in your example, Andrew.

 

Edited August 6, 2014 by deanishe

[rice.shawn]

The icon style is the color of the settings cog. You just don't show it via a preference that you set.

[deanishe]

Right. I thought it indicated whether you should use "light" or "dark" icons on that background. Pity

[Andrew]

Right. I thought it indicated whether you should use "light" or "dark" icons on that background. Pity

 

If the theme has been setup correctly, then it will indicate whether to use light or dark icons - it shows which icons Alfred uses for e.g the iTunes mini player.

[jdfwarrior]

 

Hey all,

 

Just a quick heads up that I've added some useful alfred_ environment variables into the 2.4 b277 pre-release build which may help with some aspects of your workflows. Here is what you can expect:

 

    "alfred_preferences" = "/Users/Crayons/Dropbox/Alfred/Alfred.alfredpreferences";

    "alfred_preferences_localhash" = adbd4f66bc3ae8493832af61a41ee609b20d8705;

    "alfred_theme" = "alfred.theme.yosemite";

    "alfred_theme_background" = "rgba(255,255,255,0.98)";

    "alfred_theme_iconstyle" = dark;

    "alfred_version" = "2.4";

    "alfred_version_build" = 276;

    "alfred_workflow_uid" = "user.workflow.FDC54875-6670-45CC-9D6B-1879F9257FBB";

 

The only one I feel needs explanation is alfred_preferences_localhash - for Alfred 2.4, non synced prefs are moving out of the standard OS X preferences as there is a Yosemite issue with prefs inheritance between Alfred Preferences.app and Alfred 2.app. Any local (mac specific) preferences are now stored within Alfred.alfredpreferences under .../preferences/local/[alfred_preferences_localhash]/ instead and use Alfred's own preferences framework.

 

Let me know if these are useful for you

 

Cheers,

Andrew

 

 

 

Would it make sense to go ahead and stretch this a little further and include a few extra variables? I was thinking something like the following..

 

"alfred_user" - Current logged in user (would save workflow devs from determining that with whoami or other methods)

"alfred_user_home" - Could potentially replace previous with this because this is typically what it would be used for

"alfred_workflow_cache" - Path to the workflows' cache directory 

"alfred_workflow_data" - Path to the workflows persistent data directory

 

I know some of those could be derived and such but it would be a lot easier if they were just provided. I remember there for a while I kept having users run into issues with a workflow or two and the problem stemmed from it not correctly identifying the cache and data store folders for some reason. I never could run down EXACTLY what was causing it. 

[rice.shawn]

Would it make sense to go ahead and stretch this a little further and include a few extra variables? I was thinking something like the following..

 

"alfred_user" - Current logged in user (would save workflow devs from determining that with whoami or other methods)

"alfred_user_home" - Could potentially replace previous with this because this is typically what it would be used for

"alfred_workflow_cache" - Path to the workflows' cache directory 

"alfred_workflow_data" - Path to the workflows persistent data directory

 

I know some of those could be derived and such but it would be a lot easier if they were just provided. I remember there for a while I kept having users run into issues with a workflow or two and the problem stemmed from it not correctly identifying the cache and data store folders for some reason. I never could run down EXACTLY what was causing it. 

 

The "alfred_user" and "alfred_user_home" aren't necessary at all. See below:

 

For AppleScript:

osascript -e 'log system attribute "USER"'
osascript -e 'log system attribute "HOME"'

For Bash:

echo ${USER}
echo ${HOME}

For PHP:

echo $_ENV['USER'];
echo $_ENV['HOME'];

echo $_SERVER['USER'];
echo $_SERVER['HOME'];

For Python

import os
print os.environ['USER']
print os.environ['HOME']

For Ruby

puts ENV['USER']
puts ENV['HOME']

Edited August 7, 2014 by Shawn Rice

[rice.shawn]

You also have PWD available in all of them the same way (current path).

 

Basically, just run

php -r 'print_r($_ENV);'

to see a list of what you have.

 

If you want to see exactly what is available in Alfred, then create a workflow with a php script filter that has the single line

print_r( $_ENV );

then turn on the debugger, run it, and see what comes out. 

[deanishe]

If the theme has been setup correctly, then it will indicate whether to use light or dark icons - it shows which icons Alfred uses for e.g the iTunes mini player.

 

Thanks. The problem for me is I try to make the "cog" very subtle in my themes, so that setting isn't useful for determining whether a workflow should use its light or dark icons (which is what I was hoping to use if for).

 

No matter. The theme background works a treat for that, as Shawn had already done the hard work of figuring out an algorithm to determine a colour's darkness

 

 

Would it make sense to go ahead and stretch this a little further and include a few extra variables? I was thinking something like the following..

 

"alfred_user" - Current logged in user (would save workflow devs from determining that with whoami or other methods)

"alfred_user_home" - Could potentially replace previous with this because this is typically what it would be used for

"alfred_workflow_cache" - Path to the workflows' cache directory 

"alfred_workflow_data" - Path to the workflows persistent data directory

 

I know some of those could be derived and such but it would be a lot easier if they were just provided. I remember there for a while I kept having users run into issues with a workflow or two and the problem stemmed from it not correctly identifying the cache and data store folders for some reason. I never could run down EXACTLY what was causing it. 

 

The cache and data paths would be useful. If a workflow script relies on those, however, you can't test it from a shell.

 

Or am I the only one who does that?

[Andrew]

Hmm, I think I'm just going to get rid of the alfred_theme_iconstyle as looking through custom themes, it's not usually setup correctly so will just be inconsistent. I'm going to think about the other bits to add though

[deanishe]

It might be handy to have the bundleid and possibly the name of the workflow.

 

I mostly use the bundleid for calculating the data/cache paths (which will hopefully be added), but also for naming, e.g., log files.

 

It'd be great not to have to parse info.plist.

[Andrew]

This is what it will look like when the next 2.4 pre-release comes out...

 

    "alfred_preferences" = "/Users/Crayons/Dropbox/Alfred/Alfred.alfredpreferences";

    "alfred_preferences_localhash" = adbd4f66bc3ae8493832af61a41ee609b20d8705;

    "alfred_theme" = "alfred.theme.yosemite";

    "alfred_theme_background" = "rgba(255,255,255,0.98)";

    "alfred_theme_subtext" = 3;

    "alfred_version" = "2.4";

    "alfred_version_build" = 277;

    "alfred_workflow_bundleid" = "com.alfredapp.david.googlesuggest";

    "alfred_workflow_cache" = "/Users/Crayons/Library/Caches/com.runningwithcrayons.Alfred-2/Workflow Data/com.alfredapp.david.googlesuggest";

    "alfred_workflow_data" = "/Users/Crayons/Library/Application Support/Alfred 2/Workflow Data/com.alfredapp.david.googlesuggest";

    "alfred_workflow_name" = "Google Suggest";

    "alfred_workflow_uid" = "user.workflow.B0AC54EC-601C-479A-9428-01F9FD732959";

 

The user folder is already set as USER and home as HOME.

 

I'm putting the theme subtext mode in so developers can tweak the result text based on the user selected mode, but I'd rather not see a workflow's result text being really bloaty as the main reason users generally hide the subtext is to make Alfred look cleaner.

[rice.shawn]

The cache and data paths would be useful. If a workflow script relies on those, however, you can't test it from a shell.

 

Or am I the only one who does that?

 

That's how I roll.

 

Hmm, I think I'm just going to get rid of the alfred_theme_iconstyle as looking through custom themes, it's not usually setup correctly so will just be inconsistent.

 

I always forget the the cog exists. For the same reason people hide the subtext, I hide the cog. Besides, it's so much faster for me to press ctrl+space; cmd+,. And, really, that does seem more like the Alfred way, or am I simply justifying that I'm (probably) guilty of setting up my themes incorrectly?

[deanishe]

Is it really incorrect to want a subtler colour for the cog?

[Andrew]

Alfred 2.4 b278 is now on the pre-release channel if you'd like access to these environment vars

[Carlos-Sz]

Alfred 2.4 b278 is now on the pre-release channel if you'd like access to these environment vars

 

Great. They seem to be working fine with AppleScript.

[deanishe]

Added support to Alfred-Workflow. Currently only used internally to save parsing info.plist, but I'm sure someone will think of other uses.