vitor Posted April 11, 2013 Share Posted April 11, 2013 (edited) So here’s what I’m trying to do. I have some workflows (including another I’ll share as soon as I can solve this) that need some files (config and others) that should not be written‐over after updates. It is my understanding that you can have your bundle ID serve as the directory in Alfred where to store these files, but I can’t find any simple examples on how to effectively do this. For this specific workflow, I have a file — list.txt — that’s updated (lines appended, delete, modified) with almost every action. It’s already fully working, but in doing options like if [[ this ]]; then rm list.txt elif [[ that ]]; then open list.txt fi these act on the file, on the same directory as the workflow. However, this also means that the file will be deleted whenever you update the workflow. So I’m looking for the way to do it on a file outside of it’s directory, naturally on the directories we already can use to store settings with Alfred workflows.It has to be done in bash (as to be seamlessly integrated with the script), and it should be, preferably, a straightforward process. The problem is I do not know where to begin. Does Alfred have some special variable to access files in that directory, do I have to set it up, what? Thank you in advance. Edited April 11, 2013 by Vítor Link to comment
vdesabou Posted April 11, 2013 Share Posted April 11, 2013 (edited) I believe this post will help you to do what you want http://www.alfredforum.com/topic/1920-bash-workflow-handler/ See also my last post here http://www.alfredforum.com/topic/1920-bash-workflow-handler/?p=10348 Edited April 11, 2013 by vdesabou Link to comment
vitor Posted April 11, 2013 Author Share Posted April 11, 2013 (edited) That’s it? That’s ridiculous(ly easy). This should really be somewhere more prominent. I don’t even need all the options of that script, I just made a prefsDirScript with #!/bin/bash bundleID=$(/usr/libexec/PlistBuddy -c "Print :bundleid" "info.plist") prefsDir="${HOME}/Library/Application Support/Alfred 2/Workflow Data/${bundleID}" if [[ ! -d "${prefsDir}" ]]; then mkdir "${prefsDir}" fi and I source that.Thank you for your help. Edited April 12, 2013 by Vítor vdesabou 1 Link to comment
jdfwarrior Posted April 12, 2013 Share Posted April 12, 2013 That’s it? That’s ridiculous(ly easy). This should really be somewhere more prominent. I don’t even need all the options of that script, I just made a prefsDirScript with #!/bin/bash bundleID=$(/usr/libexec/PlistBuddy -c "Print :bundleid" "info.plist") prefsDir="${HOME}/Library/Application Support/Alfred 2/Workflow Data/${bundleID}" if [[ ! -d "${prefsDir}" ]]; then mkdir "${prefsDir}" fiand I source that.Thank you for your help. Also wouldn't have to use plist buddy. Could just use defaults read command to read bundleid. That's what I do in my workflows Link to comment
vitor Posted April 12, 2013 Author Share Posted April 12, 2013 (edited) David Ferguson, on 12 Apr 2013 - 04:02, said: Also wouldn't have to use plist buddy. Could just use defaults read command to read bundleid. That's what I do in my workflows Seems to be a bit cleaner, yes. I’ll update the previous answer. Thank you. Got it to work by doing defaults read "$(pwd)/info" bundleid Do you use a different method? Edited April 12, 2013 by Vítor Link to comment
_mk_ Posted April 12, 2013 Share Posted April 12, 2013 #!/bin/bash bundleID=$(defaults read "$(pwd)/info" bundleid) prefsDir="${HOME}/Library/Application Support/Alfred 2/Workflow Data/${bundleID}" if [[ ! -d "${prefsDir}" ]]; then mkdir "${prefsDir}" fi You could also use the setPref and getPref functions of the workflowHandler to save key=value pairs in a file called settings inside the workflow's cache or data dir. That will also take care of creating the folder and file for you. If you still want to maintain the file on you own, there is a new function in workflowHandler to get the data dir: . workflowHandler.sh prefsDir=$(getDataDir) Also wouldn't have to use plist buddy. Could just use defaults read command to read bundleid. That's what I do in my workflows Using the defaults command to work with plist files is deprecated. See the comment in the default man page: WARNING: The defaults command will be changed in an upcoming major release to only operate on preferences domains. General plist manipulation utilities will be folded into a different command-line program. Link to comment
jdfwarrior Posted April 12, 2013 Share Posted April 12, 2013 Using the defaults command to work with plist files is deprecated. See the comment in the default man page: WARNING: The defaults command will be changed in an upcoming major release to only operate on preferences domains. General plist manipulation utilities will be folded into a different command-line program. Interesting. Had never noticed that. Hopefully that replacement isn't plist buddy. It works but isn't a very simple fix for doing some things. Link to comment
vitor Posted April 12, 2013 Author Share Posted April 12, 2013 (edited) Using the defaults command to work with plist files is deprecated. See the comment in the default man page: WARNING: The defaults command will be changed in an upcoming major release to only operate on preferences domains. General plist manipulation utilities will be folded into a different command-line program. And I had just updated the github repos. Changed back. You could also use the setPref and getPref functions of the workflowHandler to save key=value pairs in a file called settings inside the workflow's cache or data dir. That will also take care of creating the folder and file for you. If you still want to maintain the file on you own, there is a new function in workflowHandler to get the data dir: . workflowHandler.sh prefsDir=$(getDataDir) I like your script a lot, it’s even beautiful to look at (not joking). However, it’s the difference between 8 and 121 lines that worries me. It’s probably negligible, but still. On the other hand, it is a good looking script, and my code would probably be better served with it. However, I also share my workflows under a very permissive license (it’s basically public domain), and hindering those sharing capabilities by having a license on one of the files feels wrong. Edited April 12, 2013 by Vítor Link to comment
_mk_ Posted April 12, 2013 Share Posted April 12, 2013 The 121 lines compared to 8 lines is only valid as long as you only need the code once. But if you have to maintain several script filters using that code then i's worth using the workflowHandler IMHO. You do not have to worry about the license. It's only a CC attribution license. The only thing required to use the script is to give a link back to the GitHub repo. Link to comment
vitor Posted April 12, 2013 Author Share Posted April 12, 2013 The 121 lines compared to 8 lines is only valid as long as you only need the code once. But if you have to maintain several script filters using that code then i's worth using the workflowHandler IMHO. Yes, but I can also source those 8 lines on the beginning of the script, just like I can the 121. You do not have to worry about the license. It's only a CC attribution license. The only thing required to use the script is to give a link back to the GitHub repo. Yes, I understand that, but compare it to my license, that says I don’t care, do whatever you want with this. If you make any changes that could benefit any of the scripts, I’d certainly appreciate if you’d share them (perhaps I could incorporate them), but it’s not at all required. No attribution necessary (appreciated, but certainly not required), and no restrictions whatsoever. What this means is that I’d have to change it to mean “Do whatever you want with it, except on this tiny detail”. Since I share all of my workflows on a single repo, that also means I wouldn’t be able to have a general license, but I’d have to do it case by case. It’s just too much cognitive load, and I want people who use my code to be free of that. I was once a complete beginner too, and I remember the difference that makes. I certainly respect your decision of sharing your code under any license you deem fit, but on these projects I cannot accept any contribution that’d limit their openness even the slightest. Link to comment
_mk_ Posted April 12, 2013 Share Posted April 12, 2013 Got it. Changed the license accordingly. So feel free to include it in your projects and do whatever you want with it Link to comment
vitor Posted April 12, 2013 Author Share Posted April 12, 2013 Got it. Changed the license accordingly. So feel free to include it in your projects and do whatever you want with it Wow, thank you very much, I really appreciate it. I’m already implementing it in my workflows, and it really is a pleasure to use, it’s letting me remove some (now unnecessary) cruft. Link to comment
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now