deanishe

Alfred uses NSTask, AFAIK. All processes inherit their parent process's environment, unless the parent specifies a modified environment. In Alfred's case, it does pass the processes it launches a customised environment (it adds its own alfred_* variables, sets LC_CTYPE to ensure UTF-8, and a couple of variables to keep Python sweet). From my tests, it appears that Alfred deliberately resets PATH to the system default when it runs subprocesses. I set both PATH and PYTHONPATH in my OS X environment. Alfred doesn't remove my own entries from PYTHONPATH but it does from PATH. Bug, imo. I can see Andrew wanting to ensure a consistent environment for workflows to prevent issues, but customising launchd environment variables is not a super simple thing to do, so it seems to me that someone who has modified their environment knows what they're doing and has a good reason for doing so.

Alfred does honour some of your launchd environment settings, but PATH doesn't appear to be one of them. (That is to say, if you set a random variable via launchctl, it shows up in Alfred, but Alfred always sets PATH to /usr/bin:/bin:/usr/sbin:/sbin.) The only way I know to get around this is to run Alfred from a shell (i.e. run /Applications/Alfred\ 3.app/Contents/MacOS/Alfred\ 3 not open -a "Alfred 3"). Might be worth submitting a feature request/bug report. Applications shouldn't be ignoring your environment settings.

That's not right. Alfred should be able to find your ePubs/PDFs etc. just fine: an Alfred File Filter is how I search my Calibre library. I assumed you needed access to the tags or some other metadata, and that's why you're after accessing Calibre's database directly.

Nice one. FWIW, all the quotes in the code samples are "smart", and therefore borked. Might be worth looking into that.

This workflow is designed for that sort of thing. You can keep your bookmarks in an Excel sheet. The workflow will notice any changes and update accordingly.

Glad you got it working. Did you just do tell application "Excel" to activate?

You can't use the built-in 1P feature that way, no. It'd be pretty simple to search the exported logins yourself, however.

Yes, it would. But this is clearly 100% an Excel thing, so what exactly are you expecting on an Alfred forum? Just out of interest, like. But what is your actual question for Alfred users?

What do you mean by that? urlencode in Py2 doesn't have an encoding parameter, and Py3 would require you to specify encoding='utf-8'. But Alfred-Workflow doesn't support Py3.

To get 1Password to auto-login for you, you have to add the appropriate 1P command to the URL. You need to parse the bookmarks-default.json file in ~/Library/Application Support/1Password 4/3rd Party Integration, find the appropriate hash for the URL, then add it in the onepasswdfill parameter. So, if an entry in bookmarks-default.json looks like this: [ "6426A85E67B35015DF5C6A55085CC186", "www.domain.com", "https://www.domain.com/administration" ] Then you need to add the hash to the URL and open https://www.domain.com/administration?onepasswdfill=6426A85E67B35015DF5C6A55085CC186

That depends on whether you can automate the conversion with a bit of scripting or not… JSON isn't for humans, it's for computers. As such, it can be a lot easier to work with than CSV/XML because JSON data types map very closely to standard types in programming languages.

Download a collection of Alfred snippets and look at the file. It's a ZIP file containing one JSON file per snippet. Build one of those and you can import your snippets all at once.

Those are your two options. If you want to be able to go back up, you either need the multi-level query or you have to add an extra "Back" or "Up" item to your results and handle navigating that way.

Should be fixed in v0.7.1 Or enter ssh workflow:update in Alfred.

It's been noted many times before, but I suppose it bears repeating: This isn't a five-minute job, so you're much more likely to get your workflow if you at least try to implement it yourself and ask for help rather than straight up asking someone to do all the work for you.

I can't actually run the workflow because I don't have a harvest account (never heard of it, tbh). But why can't you connect your first Script Filter to another Script Filter to perform the second stage? Same goes for your settings. It looks like you've copied David's multi-step example, but that was a workaround for Alfred 2, which doesn't support connecting multiple Script Filters together. If you really must use a single Script Filter for two stages, the usual way to do that is to use a delimiter in your query: The Script Filter checks if the delimiter is present in the query. If not, it shows the list of smart folders (or projects in your case). Each item has valid=false and autocomplete set to the name (or id) of the folder plus the delimiter (so ↩ or ⇥ autocompletes the name/id and calls the Script Filter again with it). If the delimiter is in the query, the Script Filter loads the folder (project) specified by the first half of the query, filters its contents by the second half of the query, and shows the results in Alfred. Workflow and source code are here. Another thing if you're planning on distributing the workflow: You're using the wrong data directory. Your relative path works for folks who don't sync their workflows, but will be in the wrong place for those who do (the workflow will be in Dropbox or some other folder, not ~/Library/Application Support/Alfred 3). Get the correct path from the alfred_workflow_data environment variable, i.e. $dir = getenv('alfred_workflow_data');

<<< $var totally makes sense with a single command. The order of arguments is only an issue (for me) when piping several commands together and, particularly, when passing input to a multi-line loop. I don't think there's any reasonable alternative in that case, though, is there? Best thing I ever did WRT shell scripting was switch to zsh to be honest. It takes a few of the roughest edges off bash. I did rather get the impression you were saying there was something fundamentally broken with echoing to a pipe along the lines of "don't roll your own XML". In any case, I'll bear your advice in mind and try to avoid using echo and cat with pipes in future. Thanks for the explanation.

1Password stores your passwords as encrypted files, but not ones any other program can decrypt, so yeah… And it is pretty expensive. I'd prefer an open source solution, but I'm not aware of any good ones that work on iOS and OS X. So if you know of any, let me know…

Regarding your blog post: That's 100% false. AgileBits does not have access to your passwords. Encryption/decryption takes place solely on your devices. There is also no requirement that your data ever leave your own devices. If you need to sync, you can do that directly between devices over WiFi. As for preventing you retrieving your data, you can export them at any time from the desktop application.

The question isn't very clear. How can an item take time after the user chooses it if you aren't launching another script? Could you post your workflow somewhere, so we can see what you're doing?

⇧⌘E It's in the File menu.

You can simulate ⌘V and ⌘R using AppleScript to paste and run the query: tell application "Sequel Pro" activate tell application "System Events" keystroke "v" using command down -- wait 1/5th of a second for the paste to complete delay 0.2 keystroke "r" using command down end tell end tell

Thanks for the explanation. echo is a built-in, unlike cat, so would there still be an extra process (due to the pipe, perhaps)? The main reason I avoid using < or <<< is that I find putting the input at the end hinders readability. It violates the normally left-to-right flow, and I'm generally not a fan of short but cryptic variables and operators (which is why I usually write >/dev/stderr instead of >&2). With things like parameter substitution or zsh's head/tail/extension modifiers, I can simply never remember the syntax or option names. For anything other than -f or -d, I always need to open test's man page. That's also one of the two main reasons I gave up on Ruby and went with Python instead (the other being that Ruby sucked for non-ASCII text at the time).

The workflow generates an ssh URL based on the hostname, port etc. (in this case ssh://zzzz@x.x.x.x:yyyy). As such, ssh will read the options for Host x.x.x.x, not for Host myserver. I'll look into changing the workflow, so hosts read from ~/.ssh/config will have URLs matching the Host, e.g. ssh://myserver instead of ssh://zzzz@x.x.x.x:yyyy.

Yup. Set variables. Put this script in a Run Script action with Language = /usr/bin/python from datetime import date, timedelta import json today = date.today() tomorrow = today + timedelta(days=1) d = {'alfredworkflow': {'variables': {'today': today.strftime('%Y-%m-%d'), 'tomorrow': tomorrow.strftime('%Y-%m-%d')}}} print json.dumps(d) That will set workflow variables today and tomorrow with today's and tomorrow's date respectively in format YYYY-MM-DD.