deanishe

I had a play with ATS to see how "hard" its requirements are. As best as I can tell, its requirements only apply to the application itself. Subprocesses run via NSTask are unaffected by ATS. There is one interesting exception: If you try to run a program that uses NSURLSession and is located in the Xcode project directory, ATS will be applied. You can bundle the same program with your app's resources, or run it from anywhere else, and ATS restrictions are not applied.

Out of interest, how does this affect workflows? My understanding of ATS is that it only applies to Cocoa HTTP libraries and types. Would I be right in thinking it would apply to workflows that use Cocoa libraries, but not any others? That is to say, regardless of what Andrew does with Alfred, the system Python on everything before El Cap (i.e. pre-Python 2.7.9) will still perform no validation of SSL/TLS certificates. (Neither does file_get_contents() in PHP, AFAIK.)

FWIW, dict.cc makes their database available for download here. If you use the dictionary a lot, I'd recommend grabbing that and building an offline workflow based on it, as it's way faster (and far more reliable) than one that parses the HTML output of an online search. I made one for myself years ago, but I won't release it because you're not allowed to distribute the wordlist

There is no need to use multiple actions for this. You can run AppleScripts from Python or chain the scripts together in a single Run Script Action using bash pipes: osascript GetSafariURL.scpt | python fix_url.py | osascript OpenURLinSafari.scpt

What kind of server?

Set your Keyword to Argument Required.

It looks like an encoding issue. Alfred uses UTF-8, but tells workflows (by omission) that it's using ASCII. Here's something you can try. Open the workflow in Alfred Preferences, double-click the "todo" Script Filter and change the Script from this: /usr/bin/ruby ./main.rb {query} to this: /usr/bin/ruby -U ./main.rb {query} That should force Ruby to use UTF-8 instead of ASCII, and Cyrillic characters should work. Handling non-ASCII characters is often more complicated than just using the right encoding, so you still might have some problems. In particular, having non-ASCII characters in your sync directory path (/Users/konstantinpopov/Dropbox/Приложения/Alfred.alfredpreferences/workflows/) is quite likely to cause issues with UTF-8/Unicode-unaware workflows. If my first suggestion doesn't help and/or you have issues with other workflows, try renaming Приложения to Applications or some other ASCII name. A stupid amount of software can't handle non-ASCII paths.

It's probably best to get into the habit of typing a letter or two of the action's name. That gets you a much better hit rate. Fixed hotkeys is a decent idea, but it's not really in sync with the way Alfred works in general (prioritising your favourites). That said, Alfred doesn't appear to apply its knowledge to File Actions, so there's a case to be made that Alfred's current behaviour is sub-optimal from either point of view.

It'd be possible, but why bother? Most sensible people use separate scripts in the workflow folder (so you can use a real editor and get useful error messages) and call them via /bin/bash anyway: /usr/bin/tclsh ./my-workflow-script.tcl "{query}"

This has been discussed before, but I can't find the thread. The upshot is, that would totally break the way Alfred works. As things stand, when it comes to file search, you can already hit right-arrow and perform file actions on one or more results. I would suggest implementing any actions you need as File Actions.

Writing a workflow is quite a bit more complicated: you'll probably have to parse the HTML response to show the results (you can't just open the search results in your browser).

If you want to search a specific category, you can use: http://www.ibdb.com/Search/Persons/{query} Otherwise, you're out of luck with a web search. It could be done with a workflow, though.

No closing quote: Don't forget about Alfred's debugger. Seeing as you're using Alfred-Workflow, you can also use the query workflow:openlog to view the log file (which will contain any errors in your Python scripts).

What you're missing is a function function run(argv) { // your code goes here... } When you run a script in Script Editor or from the command line, it will call the run function if there is one. argv will be an array of any command-line arguments (if you run the script on the command line). You can just write your code at the top level, too, but obviously you can't use return. In that case, the script output is typically the result of the last expression. So in your case, it'll probably work if you just leave off the final return secondsDecimal statement.

If I were you, I wouldn't use this workflow for the time being. It appears to generate passwords based on the sample word lists included. These lists are much too short to generate secure passwords from (unless they're 10+ words).

It depends. It usually only takes a second or two. It sometimes takes 10 or 15 seconds.

This is kind of a biggie. Most workflow elements are so badly described in the UI that (if you have more than a couple of elements) you've no idea what is what without opening their sheets. A tooltip or two would be a massive help. Personally, due to the opacity of workflow elements and the difficulty of rearranging them in the editor, I try to put as much of the UX complexity in the script(s) as possible, and not in the UI.

I have this problem regularly. As the thought of waiting 10 seconds is sickening to me, instead of searching for the application, I usually browse the /Applications directory instead by typing /App<tab>. You can also reduce (or occupy) those 10 seconds a bit by reloading Alfred's cache with the query "reload".

Have you tried running the commands as normal Run Script actions instead of Terminal Command ones?

Running the command on a file is entirely trivial to do. The question is: how does the input and output work? You want input via a File Action, which is super simple. But what about the output files? Are the original files replaced? Are the optimised files saved to the same directory as the originals with a different name, e.g. NAME.optimised.EXT? Are they saved with the same name, but to a different directory? Are the original files renamed to, say, NAME.orig.EXT, and the optimised versions saved under the original names? Unless you're overwriting the originals, some manner of path/filename manipulation is going to be necessary.

FWIW, a shortcut (no File Action necessary) to browsing a specific folder in Alfred can be had by attaching an AppleScript to a keyword or hotkey (or whatever). If you start an Alfred query with "/" or "~" (which means "my home directory"), and as long as the provided query is a valid path, Alfred goes into Browse mode. So, to browse /Users/Me/Documents/My Triggered Folder you could attach your keyword/hotkey to the following AppleScript: tell application "Alfred 2" to search "~/Documents/My Triggered Folder"

If that's directed at me, I just pasted a few lines of code I found into Rodger's script. Thank him. Left as an exercise to the reader is changing the bytes (and possibly KB) to have zero decimal places and to remove trailing zeroes (and decimal points) from the output. I hate both of them, to be honest. Give me a "real" programming language like Python or Ruby any day. Things you come to take for granted in a programming language are usually super-esoteric in bash and overly-complicated in AppleScript. I think I got the rounding code from Stack Overflow. Like I say, I don't really understand exactly how it works, but I tested it, and it does! EDIT: Tell a lie, the code is from here. EDIT 2: I've had a look at the AppleScript docs and now I do understand how roundThis() works. I'd never have thought of it myself, though…

You don't need this bit. You get the Finder selection in your AppleScript. This should do the trick: on roundThis(n, places) set x to 10 ^ places (((n * x) + 0.5) div 1) / x end roundThis on humanSize(bytes) set i to 1 set n to bytes set units to {"B", "KB", "MB", "GB", "TB"} repeat while i < (count of units) and n > 1000 if n > 1000 then set n to n / 1000 set i to i + 1 end if end repeat if i > 2 then set n to roundThis(n, 2) else set n to roundThis(n, 1) end if return (n as string) & " " & (item i of units) as string end humanSize tell application "Finder" set selectedItem to (item 1 of (get selection)) set theBytes to (size of selectedItem) "Size: " & my humanSize(theBytes) end tell Don't ask me how the roundThis() function works.

TL;DR What you're suggesting is a very clever solution. What I'm saying is that it might not be complete, depending on system configuration. It absolutely should work; you just might need to add actions to a few more folders. Finder sometimes lies about files and especially their names. If you open the real Trash in Finder and do Get Info, then open the Trash/.Trash hidden directory in your home directory and also do Get Info, you'll see they're not the same. In particular, there is no "Where" for the real Trash because it isn't a real folder: You can see that the "Trash" directory in your home directory is really called ".Trash" (which is what you see in a terminal). More importantly, you can see that not all files that are in the Trash are actually in the ~/.Trash folder. Any files you trash are moved to a special directory on the same partition. In the case of the partition your home directory is on, that's ~/.Trash. On other partitions, a subdirectory of the .Trashes directory at the root of the partition is used. The "missing" files in the screenshot are three directories, totalling a couple of gigabytes, that were on a different partition (/Volumes/Media in this case), so they are now in the /Volumes/Media/.Trashes/501 directory on that partition (501 is my user ID), not in ~/.Trash. That is to say, adding a folder action to ~/.Trash will work if your computer only has one drive and partition. If it has more, you will need to also add folder actions to the other directories that contain trashed files, otherwise they will sit in the Trash forever.

It's not that simple. Like I said above, the directory is called ~/.Trash, not ~/Trash (its name starts with a period—that's what makes it hidden), and it's not the only directory that contains trashed files.