Quicksilver stores complete paths rather than relative paths from user folder

[ingling]

We work in a complex environment where we have a standardized set of Quicksilver triggers across a bunch of computers.

If we could have Quicksilver draw from a single settings file to multiple computers, that would be fantastic. All it requires is a change to the way user folder file paths are stored in the Quicksilver Triggers.plist.

Currently, Quicksilver stores all the file paths in the Triggers.plist as paths spelling out the User folder:

/Users/[username]/Dropbox/Clipart Project/Scripts/Add Underbase to Layer Name.scpt

I tried putting a simlink at /Library/Application Support/Quicksilver/Triggers.plist that links to a copy of Triggers.plist on a dropbox that's shared with everyone.

I used find and replace on the Dropbox copy to replace all instances of "/Users/[username] with" "~", and it works! Multiple computers could share a single set of triggers, and I could add triggers and change them and they'd work live on other people's computers, as long as I ran the find and replace.

However, it's not usefully functional because all the time, Quicksilver rewrites all the paths to their former state, breaking it on everyone's computer except for the one that updated all the paths.

It would be really great if Quicksilver started all paths to items in the user's folder with "~/" instead of "Users/[Username]/" so that settings files can be shared.

I've honestly considered changing everyone's computer to use the same username just to get around this, but it seems like a kludgy work around.

FYI, if it helps influence anyone, we donated $125.00 to Quicksilver on September 19th... we would have put the donation specifically toward this, if I'd known about it then.

Thanks for considering this request,

Tom.

[tiennou]

Hmm, that's an interesting setup, to say the least ;-). It reminds me that a loooong time ago, there was some code to do things related to Bonjour, which I think was meant to make other QS instances remotely accessible.

Anyway, the use case is interesting, and I think it can be handled easily. The hard thing is actually making those accesses reliably synchronized when multiple QSs are running at the same time (IIRC we have a tendency to eagerly write that Trigger file, and there was work to make it less eager, @skurfer ?). I'll try to come up with something anyway ;-).

About your workaround, you could also try :

• creating symlinks for just the "username" part — e.g. decide that you are responsible for writing the file, so by creating symlinks of /Users/[Username] as /Users/ingling the resolution process should work. But then everyone would resave and we'd be back at square one, unless if you symlinked every username on every computer — depending on your network configuration this could be impossible.
• if you can investigate how Dropbox reacts to hardlinks, you could hardlink your script somewhere not dependent on ~ (like /Library/Scripts) and use that location in the Trigger.

[skurfer]

Changing the identifier for files to use ~ shouldn’t be that complicated. (Then someone will complain that they can no longer share triggers among multiple users on the same machine. :wink:)

That will break people’s mnemonics, though. We’d need to check the build number on launch and rewrite any paths found when the new version runs for the first time.

As for sharing the configuration, I wouldn’t recommend having all users literally point to the same file. It might be safer to have a script that can add the shared triggers. (Maybe using Python’s plistlib or something.) That would allow people to have their own personal triggers without forcing them on everyone else.

@tiennou is correct that, in 1.2.0, the Triggers.plist won’t get overwritten all the time. It used to get replaced on launch when nothing had changed. That alone might alleviate a lot of your problems if you continue to share the file.

[ingling]

I'm fine with forcing the same trigger set on everyone... this is a production environment. I don't know Python... Regarding the workaround, let me make sure we're on the same page here - Both the triggers.plist and the scripts will be in dropbox, which will be in the user folder. However, I can make a symlink on each individual computer at the same non-relative path, that points to the dropbox scripts folder on that computer. Then assign the script triggers in dropbox using the non-relative path to the symlink to the dropbox folder, so it will be the same on every machine?

[tiennou]

@ingling : Yep, that's the idea. Note that you'll have to make a hardlink, else QS will resolve it to inside the user's folder and you'll be back at square one (hardlinks are made using plain ln, without the -s option). This will create a real file (contrary to symlinks), but which share the "inode" of another file (equivalent to making the same file exist in two locations in the filesystem). The problem is that I have no idea how Dropbox handles file replacements when a new file gets propagated : if it replaces contents (which doesn't change the inode, you're good). If it instead unlinks and create a new one at the same place, then the inode will change and your mirror file will be "orphaned" (i.e. won't be kept in sync). You can use ls -i to see the inode number.

[tiennou]

After a quick test here, I haven't seen the inode change, but I only have one machine to test, so it's pretty limited. Maybe that'll work :wink:.

[tiennou]

@skurfer Then maybe the Triggers should be objects in the Catalog, and we could have a way to handle multiple Catalogs, as well as the ability to graft others Catalogs at runtime, depending on location and discovered Bonjour hosts :laughing:.

[ingling]

Sorry guys, I was out of town on business for a few days. Will get back on this tomorrow and test the hard-link non-relative file-path method tomorrow. Thanks for all the quick help! A more integral, less hack-y method in the future would be highly welcome!

Thanks again, I'll update this after we test,

Tom.

[ingling]

using "ln" in terminal won't hardlink a folder. It returns: ln: /Users/thomasingling/Dropbox/Clipart Project/scripts: Is a directory

Do I have to do this - compile this c program and use hlink?

http://stackoverflow.com/questions/80875/what-is-the-unix-command-to-create-a-hardlink-to-a-directory-in-os-x

I use the Terminal some, but this is starting to teeter on the edge of my comfort level.

[tiennou]

Directory hardlinks are mostly forbidden because weird things can happen, for example if you rm -R one (or even move to trash one of the copies), the contents will be removed and thus both will end up empty.

What I'd do is something like this, symlinking the individual scripts — and keeping the script handy in case scripts are added frequently.

[ingling]

If I symlink the original scripts, then don't I have to go to each computer and create that symlink each time I add a script? Going to each computer and using the terminal and symlinking the script... I feel like it would be faster to just set up the trigger in Quicksilver on each computer. Which gets me back to not changing anything. OSX supports Folder Actions, I can maybe make a Folder Action that, every time a script gets added to the scripts folder, it makes a symlink to that script at the non-relative path folder. Maybe I should just go back to giving everyone the same user name so the paths will be the same.

[stale[bot]]

This issue hasn't been updated in over 2 years. It has been marked as 'stale' and will be closed in 30 days. Please check whether this is still an issue with the latest version of Quicksilver. If so, update or comment on this issue to keep it open.