deanishe

Ta for the plug The workflow also has a forum thread here.

Thanks, Jono. Once again, that's much better than the icon I used. Will update the icon in the next version.

Chances are, when you run the command from Terminal, /usr/local/bin will be first on your PATH (use echo $PATH to find out), so calling git or rsync in a script will run the versions in /usr/local/bin. Alfred, however, ignores your PATH and will use the git and rsync in /usr/bin. I'm guessing you installed git and rsync from homebrew or the like, so they're almost certainly newer versions that the system ones. It's possible one of your options isn't understood by the older versions. You should always use full paths, e.g. /usr/bin/git not just git in workflow scripts to ensure you're using the same executables from Terminal and Alfred. .git is the folder that git creates when you make a directory a git repository. It's where .git keeps all its data. Remove that folder and you no longer have a repository. The --git-dir and --work-tree options tell git which directory it should operate on. By default, it uses the current working directory and searches up the file tree till it finds a .git directory. Personally, I wouldn't bother with those, but would do a chdir to the repository directory and just run /usr/bin/git add .. You might have to chdir back to the previous working directory afterwards (which is the workflow root directory when run from Alfred).

How are you generating the XML? Are you sure it's actually UTF-8 encoded? It still looks like an encoding problem (i.e. it's correctly encoded for xmlformat, but not when generated by your script).

That's a very good idea. I've added it to the workflow and the new version (1.1) is available from Packal and GitHub (links in the OP).

Unfortunately not: it uses mdfind, aka Spotlight, for searching. Actually calling find on a large volume, especially a network volume, would be a good few orders of magnitude slower. The reason Fuzzy Folders is so slow is that it calls mdfind/Spotlight with the last "word" of the query and filters backwards from there. It often ends up fully retrieving several thousand results from Spotlight, which it then filters according to your query. FWIW, an index time of 24+ hours is pretty normal for a large drive, and longer for a network drive. Once the initial index is done, it's usually super fast.

It looks like your system handlers settings are messed up. Try rebuilding your launch services database, and use RCDefaultApp to check you have the right application assigned to open URLs.

For anyone having the same problem as above, if you deselect "Double Quotes" in the escaping options of the Run Script action, you can then add multi-word values enclosed in double quotes, e.g. boom temp key "this is a long string."

Spotlight (and therefore Alfred) can search network volumes (like your Synology), it's just not turned on by default. You have to do it via Terminal, but it's pretty simple to do. See here.

For anyone who, like me, was getting timeout errors on Packal, the site is rock-solid now. Great work, Shawn.

There's a list here. Webapps like Instapaper/Pocket, Pinboard, RSS readers and most others that use URLs provide bookmarklets for you to save/add pages to their services. I use them a lot on my iPhone, too, to send URLs to various apps as a way to get around iOS's lack of Android's refined sharing model.

I hope he doesn't mind my mentioning it, but Shawn is currently working on something to do exactly this. It'll work for common utilities like terminal-notifier and cocoaDialog (which are both built in, IIRC) and for versioned PHP and bash libraries. Unfortunately, it looks like Ruby and Python won't be supported for a long time, if ever, due to the way bundler and pip work Thanks for the info. I would be calling Cocoa classes directly from Python, not via AppleScript. I'll give it a go and see what happens. I imagine I'll get the silly Python rocket icon, though, even if GateKeeper doesn't complain

Don't get me wrong, I fully appreciate why you did it. It's not the size of it that bothers me, more the idea that there are 50 copies of the same thing. It's silly, I know, but it irks the coder in me in much the same way I imagine the wrong icons in the notifications bother you. As you wrote your own notifier, do you perhaps know if GateKeeper will complain if a Ruby/Python script tries to post a notification via their respective Cocoa bridges? I'm thinking of trying to add notifications to my Python workflow library, but there's no point if GateKeeper's going to kill it.

That makes a lot of sense. I'll stick with my bookmarks bar, I guess. I couldn't live without the mobile sync Safari and Chrome provide.

Yeah, the problem is in the way you're passing stuff to subprocess.Popen. First of all, you really shouldn't be using shell=True unless absolutely necessary. Here it isn't. Use the full path of the executable instead. With subprocess.Popen (and .call, .check_output etc.), you're supposed to pass the program as the first item in the args list and subsequent arguments in the rest of args. You don't mash them all together like with os.system or the exec functions in other languages. The error you were getting is because you're passing "/Users/ritashugisha/Downloads/file.txt" "/Users/ritashugisha/Downloads/new.txt" as a single argument (and hence filepath), not two separate arguments. If you absolutely have to pass multiple arguments in one {query}, this line: 'tool "%s" "%s"' % (item, '%s.%s' % (os.path.splitext(item)[0], i)) should look something more like this: DELIMITER = '➜' '/full/path/to/tool {0} {1} {0} {2}.{3}'.format(DELIMITER, item, os.path.splitext(item)[0], i) (I don't know if you've got from __future__ import unicode_literals at the top of your script, but if you haven't this code will break, as will your code with non-ASCII data. Change DELIMITER = '➜' to DELIMITER = u'➜' if you don't want it to break immediately, add from __future__ import unicode_literals (or prepend every literal strings with u) if you don't want your code to break with non-ASCII input, too.)And the following script should split the query into the individual arguments and pass those to subprocess.Popen: import subprocess DELIMITER = '➜' args = [s.strip() for s in '{query}'.split(DELIMITER)] proc = subprocess.Popen(args, stdout=subprocess.PIPE) (proc, proc_e) = proc.communicate() return proc Note: I'm drunk and haven't tested my code. No liability is accepted for errors in my code, but the basis of the error is 100% correct. I guarantee it!If it's not working at all, ask me again, and I'll sort it out in ~8 hours or so when I'm sober Also, it's perhaps worth adding that your code formatting isn't compliant with PEP8 (no extra spaces around = in assignments, for example). It's not a big deal—not by a long way—but it's kinda expected.

Marvellous idea, but is there any chance of the workflow grabbing the bookmarklets straight from the browser's bookmarks?

Is terminal-notifier signed, then? Perhaps it's just me, but I'm not a fan of including terminal-notifier or the like simply to show the right icon. It's not a big deal if it's only one or two workflows, but I'd hate for everybody to have the same idea, so I end up with 50 copies of it in my workflows folder.

It takes ~1/200th of a second to make that extra call to the shell. I don't believe you really think that matters: your Calca ToolKit workflow makes the same call to PlistBuddy 5 times in 7 lines of code instead of caching the result. One less level is not inherently good. Indeed, one more level is a very good thing if it makes the code easier to understand (which putting it in source code files does compared to embedding it in info.plist, where it's impossible to get an overview of all the code). Nobody said they have to use the command line. They can still run the scripts in Alfred (and probably should, due to the differing execution environments). And it's precisely such novices that can really use the syntax highlighting and linting help provided by a proper code editor (of which there are many excellent free ones). Passing over the fact that Alfred's debugger didn't exist when you wrote the non-debugger tutorials, the debugger's utility is distinctly limited when debugging anything but trivial scripts in Script boxes: there aren't any line numbers, and it can be a nightmare trying to figure them out thanks to the wrapping in the tiny box. And there are several other advantages to using a source code file over embedded code: For more than trivial workflows, you can write a "proper" script that takes other options/arguments—a better option than spreading code all over the place. You can import/require your scripts from others, so you don't have to copy-paste code all over the place and consequently have to fix any errors in multiple places. You can't import from a Script box. Source control is more practical: it's hard to decipher diffs of code that's embedded (in an encoded format) within an XML file. It's easier to maintain an overview because all your code is there in the workflow directory, not hidden away in info.plist. It's easier to code: you can look at more than one file at the same time. You can run the workflow in Alfred without losing your place in the code. You can almost instantly find the line throwing the error reported in the debugger, instead of grubbing around in a tiny box full of grey text. It's extremely bad form to be copy-pasting the same code into multiple scripts. It goes in a separate script that can be imported as required. Your "Calca ToolKit" workflow has 6 bash Run Scripts, each of which is 50% duplicate code. That code should be in an external file and included via source. That way, you could improve it to cache the results of the call to PlistBuddy, instead of calling it 5 times, in just one place instead of 6 separate Run Script Script boxes. (BTW, the bottommost Run Script—the calca:figure one—is broken: you have the language set to bash but the code is PHP.) It's not safer. Not in the slightest. Regardless of whether the the Script box uses bash (or any other available language) to call an external script with an argument or directly runs bash/PHP/Python/Ruby code entered in the Script box, they all use the {query} macro and the risk of code injection is exactly the same if you don't get the escaping right. Only the language of the injected code changes. If you get escaping right, you're golden; if you don't, your code is vulnerable/broken. The escaping in your Calca ToolKit is, for example, by turns broken and vulnerable to injection. Your PHP Run Scripts escape nothing, yet wrap {query} in double quotes. That means any double quote passed in {query} will break out of the quotes, and anything that PHP would normally interpolate in double quotes ($var, `shell command`) will also be executed. That is to say, it's vulnerable to exactly what you claim is only a problem with external scripts. You should escape backslashes, dollars, double quotes and backquotes. Your bash Run Scripts either also escape nothing (thus having the same vulnerability as your PHP ones) or escape everything, which will give you incorrect input (there's no need to escape spaces within double quotes). You should use exactly the same escaping options as above. As noted above, your performance argument doesn't hold water. If it mattered to you that much, it would show in your code. Yeah, I like them to see the code, too. Which is another reason not to use the Script box. It makes the code extremely hard to read compared to syntax-highlighted code in a proper editor or the nicely-highlighted code examples in your tutorials. It makes finding errors reported in the debugger much harder. Using the Script box also makes it harder for a user to tinker with the code: there's no undo function in the Script box once you've saved your changes to run the script. So, they just broke the script, and now their only option is to replace the workflow, losing all of their changes, not just the last one that broke stuff, because there's no way to reverse just that one change, unless they can remember exactly what they changed and in which line (which, of course, isn't numbered). Unless they had the sense to copy the code into an external editor… The very first thing I do if I want to understand or modify someone's workflow is to change it so it runs external scripts, not code from a Script box. I appreciate that using the Script box is the right way to go in the beginners' tutorial, but by the time you get to "advanced", the many advantages of using a proper code editor and actual scripts over the Script box should be mentioned. Putting most of the code in external files is, for all the reasons given above, a better way to write a workflow.

Why are you pasting the code into the Script boxes instead of using external scripts? What is the advantage in doing that?

Could you post the code that's actually causing the error? It could be several things.

Good work. I'm getting a GateKeeper error because your bundled "notificator" app isn't signed. Is there a reason to use it instead of puts and a standard Alfred notification?

It looks like an encoding issue. Try adding the encoding argument to your XML header: <?xml version="1.0" encoding="utf-8"?> It goes without saying that you should also ensure that the XML is encoded with the corresponding, err, encoding.

Good idea, but grc.com/Steve Gibson is not a confidence-inspiring source of passwords. Any chance of getting the passwords from a more reputable source?

Yeah, the UI "flicker" is definitely unpleasant, but I think that, on balance, one keystroke and a bit of flickering is preferable to having to hit backspace a whole bunch of times. And it does allow you to write much cleaner code when you don't have to worry about truly serpentine queries. Still, I tend to prefer the pragmatic over the pretty.

More of a UX thing, but it's a behaviour I think is great and have used in all of my workflows since I saw it in Carlos's Recent Items workflow. It's similar to the way Alfred's filesystem navigator works. A lot of workflow use "multi-level" queries using a symbol as a delimiter, e.g. keyword level1 ➣ level2 ➣ [query]. When you reach a new level the query typically looks like this, "keyword level1 ➣ level2 ➣ " (note the trailing space), ready for the user to enter a query. What Carlos's workflow does (and now also mine, cos it's awesome!) is back out to the previous level if the user deletes that trailing space, so hitting backspace on the above query would take the user back to "keyword level1 ➣ " (again with a trailing space). I think this makes a workflow much easier to use (if it's appropriate, of course), and it's pretty simple to implement (if query.endswith(DELIMITER): call_alfred_via_applescript_with_query(previous_level)). What do you guys and gals think of it?