Jump to content

Alfred 3: Environment Variable shouldn't be shared between systems


Recommended Posts

My setup is with Alfred on my laptop and mini sharing preferences by Dropbox. Works great except for the setting of variables in the latest version. I have a workflow that I am setting the path to a work directory in an environment variable. But, that path is different on the two systems. I'm going to have to move it to a storage file in the data directory instead to be different on the two systems. Since these variables would most likely be system dependent, they shouldn't be stored in the shared preferences, in my opinion.

 

Also, it would be nice to have a way to programatically alter the environment variable from launch to launch. I can use the Arg and Vars to set it different for a run on the workflow, but that is lost when the workflow completes. An option to save it would be nice.

 

Thanks.

Link to comment
Share on other sites

You can alter the environment variables programatically using PlistBuddy or whichever library to edit plists/XML.

 

I'd argue it'd be better to have a sync toggle like the Don't Export one than to just not sync the variables. Or perhaps the Don't Export can do double duty as a Don't Sync.

 

Variables that sync are a handy feature.

Link to comment
Share on other sites

You can use Applescript to test which machine a workflow is running on, and alter workflow behavior on that basis.  e.g. here is one I use with Chronosync, where the CS files have different names based on the machine:

	set theComp to computer name of (system info)
	tell application "ChronoSync"
		if theComp contains "laptop" then
			open "~/archive/laptop to USB.sync"
		else if theComp contains "home desktop" then
			open "~/Documents/ChronoSync Documents/home <> USB.sync"
		else if theComp contains "work desktop" then
			open "~/archive/atu-childermas.sync"
		else if theComp contains "another computer" then
			open "~/ChronoSync Documents/another cs doc.sync"
		end if
		Trial Sync document 1
	end tell


Also - in this example - I have a post-synchronization script set up in Chronosync which writes the date & time to a dotfile in Dropbox which my Alfred workflow reads in a script filter, so it comes up with the title "Chronosync Current Machine" and a subtitle like "Last run on Work Desktop, 2016-06-24 3:50 PM"  Basically writing a dotfile to save the last run date instead of saving it as a variable within the workflow, and to make it available easily to scripts that aren't part of the workflow.

Edited by dfay
Link to comment
Share on other sites

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