Help making non‐volatile files from a workflow with bash

[vitor]

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

[vdesabou]

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

[vitor]

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

[jdfwarrior]

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.

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

[vitor]

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

[_mk_]

#!/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.

[jdfwarrior]

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.

[vitor]

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

[_mk_]

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.

[vitor]

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.

[_mk_]

Got it.

 

Changed the license accordingly. So feel free to include it in your projects and do whatever you want with it

[vitor]

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.