Jump to content

Some new alfred_ script environment variables coming in Alfred 2.4


Recommended Posts

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
Link to comment

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.

Link to comment

 

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. 

Link to comment

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 by Shawn Rice
Link to comment

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. 

Link to comment

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?

Link to comment

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.

Link to comment

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.
Link to comment

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?

Link to comment

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