chadv

My idea is to get more from File buffer ability. It is superb right now, but I think it could be even better with drag and drop. What I mean is to select files into buffer and then would be possible to drag those anywhere we want to drop. Similar to DragonDrop app.

I was surprised this wasn't possible, but today I wanted to drag 2 items I had collected in Alfred's buffer to another app that can receive file drops. I found out that it only seems to allow dragging 1 file at a time from the buffer area. 
 
Am I missing something or is there any way to do this?  Yes I know about "actioning all items" to send buffer contents to a workflow but I specifically need to drag them in this case.
 

 
(Alfred 4.5 b1252 by the way...)

See Calling non-standard runtimes from Alfred and Understanding the scripting environment.

For personal workflow, naturally you can use whatever you like. But when sharing it’s best to target the system python precisely because you can be fairly confident of everyone’s setup.

Hi,
 
I am building a workflow and on my machine, it seems to use the right python version.
 
The same workflow on my friend's computer however doesn't work - it somehow picks the system's python 3.7 although he has the homebrew version of python installed (python 3.11) and also an anaconda.
 
How can I determine and control which python is used when in a script filter I choose "python" as the one to run?

When configuring a Run Script or Script Filter, Alfred provides a Language dropdown listing the runtimes which have historically been included with macOS. But what if you want to run a script from another language which you have installed on your system? Be it Node.js, Lua, or something else, it’s dead-simple to call them. Either:
Save your script with a proper shebang (examples: #!/usr/bin/env node; #!/usr/bin/env lua) and use External Script as the Language, pointing to your script. Use /bin/zsh (or /bin/bash) as the Language and tell the runtime to call your script (examples: node MY_SCRIPT.js; lua MY_SCRIPT.lua). The first executes (marginally) faster but the second allows you to send preset arguments to your script. They work as they are assuming the languages were installed with Homebrew, as Alfred includes its directories in its PATH.

Without intending to sound sycophantic, I just wanted to thank Andrew (and Vero) for, not only the development and release of Alfred 5 (which is a significant, and much appreciated, step forward), but the constant, considerate and always responsive support provided on these forums.
 
It's because of the continuing development and the support here that I am intensely loyal to Alfred.
 
Thank you.
 
Stephen

Looking forward to this as well. It'd be useful to place the cursor at a particular location after expansion, too.

To run just type "rapp" in Alfred bar and select the application you wish to restart.
 

 
 
More info and download
 
v1.1: Inline app search (courtesy of Carlos-Sz)

The previously released menu search workflow has been universally panned due to the poor performance of the AppleScript that dumps menu contents. The caching of results worked very poorly as a stop-gap. So, I've re-written the menu extraction in Objective-C. It's much faster. The source is here: https://github.com/ctwise/alfred-workflows
 
You can download the workflow directly from http://tedwi.se/u/db
 
To recap, this workflow lets you trigger an application's menu's from Alfred. For example, if you're in iTerm and trigger Alfred, you can type 'm view' to get a list of all menu items with 'view' in the name or that belong to the 'view' menu. Selecting one of the entries triggers the corresponding menu entry in iTerm. In one sense it gives you a command-line to control your applications.
 
The workflow has the beginnings of shortcut key display as well but it's currently disabled due to numerous bugs.
 
Update: 
 
v1.3 - Provide error message when assistive devices isn't checked.
v1.2 - Skip the Safari History and Bookmarks menus. They take too long.
v1.1 - I fixed the bug with Alfred not remembering selections and added AlleyOop support. Download from the same link.
 
Requires OS/X 10.7+.
 
---
 
You need to turn on OS/X assistive device support to allow this workflow to operate. You can find the checkbox in Settings. The settings page looks very different in recent versions of OS/X but the wording for providing access for assistive devices is very similar no matter what OS/X version you're using. Here's an image of the settings from the latest version of Mountain Lion.
 

Since Alfred now has a built-in server running in the background and is paired with iOS devices
How about a clipboard sharing feature?
Straight and seamless. 

This workflow is officially deprecated. It was released to the public domain, so I leave the record here if anyone is interested. You can still find the old source on Github.
 
Call bn with a website address and the Workflow will fetch the available logins with the corresponding success rate.

If you had the login box selected prior to calling the Workflow, hit ↵ and it’ll automatically type the username, hit ⇥ and type the password. If for any reason that did not work or you just want one of the details, use ⌃↵ or ⌥↵ to copy the username or password (respectively) to your clipboard.


 
Download | Source

Can Alfred Remote send a packet to wake a sleeping Mac at a fixed IP address?  If not, this might be a useful addition.

These should now be fixed in Alfred 2.4 b274 available as a beta build: http://blog.alfredapp.com/2014/07/25/alfred-v2-4-yosemite-fixes-and-many-improvements/

@chadv: Thanks for investigating and letting me know. Shame indeed, especially given that it hasn't been fixed in OS X 10.10 (the current public beta), which still ships with the same libiconv version (1.11).
 
Curiously, 3- and 6-byte UTF8 emoji sequences as well as those 7-byte sequences that start with an ASCII char. byte (followed by combining characters) do work properly, but the majority of emoji (4-byte sequences) do not.
 
On a side note, Terminal.app, while *rendering* emoji as expected, doesn't handle them properly in terms of cursor placement, printing the next character, and backspacing. 6-, 7-, 8-byte sequences seemingly involve combining characters, and are misinterpreted as comprising *2 or 3* characters, which has all sorts of unwanted side effects.

I think the AS solution is a bit overkill just to get the user locale. Doing the re-normalisation of the query with Andrews tool and getting the locale with
 
export LANG="$(defaults read -g AppleLocale).UTF-8" seems the be the easier solution for me. That way you can also avoid the logic to find the workflow directory.

"/Applications/Alfred 2.app/Contents/Frameworks/Alfred Framework.framework/Versions/A/Resources"

Bash scripts launched by Alfred in the context of workflows don't respect the OS X user's locale and instead default to the generic "C" locale.
 
Alfred should use the same locale that is used when a user starts an interactive shell in Terminal.app
 
(For instance, running locale in Terminal on my US-English system returns:
 
LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL= )   To verify the problem, use the following test workflow: download and install https://dl.dropboxusercontent.com/u/10047483/localetest.alfredworkflow type localetest into Alfred, which will display the effective locale in large type   To work around the problem, use the following at the beginning of your script:  
export LANG="$(defaults read -g AppleLocale).UTF-8"    Possibly related [update: NOT related - see below]: non-ANSI characters are currently encoded in unexpected ways:   In normal UTF-8 encoding, "ü" should be passed in (via {query}) as the following multi-byte sequence: expected: 0xc3 0xbc instead, Alfred currently passes: 0x75  0xcc  0x88   - 3(!) bytes

Alfred is designed to close when focus is pulled away from him and It appears that the small palette is making Alfred resign the key window when it shouldn't do, which is very likely a bug in OS X.
 
Playing around, it looks like Spotlight (which also closes when you focus on another window like Alfred) is also affected by the same issue.
 
I'll report this to Apple.
 
Cheers,
Andrew

Interesting, I can reproduce this! I'll add a ticket and see what I can do to fix this in the next release, cheers!

I've created a small command line tool which should hopefully help you re-normalise any strings:
 
https://dl.dropboxusercontent.com/u/6749767/Alfred/normalise.zip
 
If you include this in your workflow itself, you should be able to run it directly like this:
 
usage: ./normalise -form NFC й
 
You can add -verbose after NFC to see what is happening, or no arguments to see the options.
 
Let me know if that helps at all

@Andrew's normalise utility works great, but I've since found that there is an alternative using the standard utility iconv with the (somewhat obscurely named)  UTF8-MAC encoding scheme:
 
Note: The following examples use bash.
iconv expects its input via a filename or stdin.
 
Applied to the example above:
 
  # Converts NFD form of 'й' to NFC form
iconv -f UTF8-MAC <<<'й'
 
Some background:
The following examples use input string 'ü'
in NFC form, $'\xc3\xbc' - i.e., bytes 0xC3 0xBC, which is the UTF8 encoding of Unicode codepoint 0xFC in NFD form, $'u\xcc\x88' - i.e., a u - the base character - followed by bytes 0xCC 0x88, which is the UTF8 encoding of Unicode codepoint 0x308, the so-called combining diaeresis (¨). to demonstrate converting; note that in Terminal the result will always appear as ü - pipe to hexdump -C, for instance, to see the byte values.
  # NFC -> NFD
iconv -t UTF8-MAC <<<$'\xc3\xbc' # -> $'u\xcc\x88'

  # NFD -> NFC
iconv -f UTF8-MAC <<<$'u\xcc\x88' # -> $'\xc3\xbc'
 
These conversions are safe to use in that if the input string is already in the target format, it is left as is. 

This is indeed to do with normalisation, and a consequence of using NSTask. Alfred doesn't have control over the normalisation so I created a little command line app for users to re-encode, or you can use iconv. More details (and the command line tool) in this topic:
 
http://www.alfredforum.com/topic/2015-encoding-issue/
 
Cheers,
Andrew
 
[moving to closed]

Upgrade to maverick today and notice many of the scripts including some standard ruby gems raise exceptions. After a few hours debugging, the root cause identified is the encoding. Now the default is not utf-8. output from `locale` is 
 
LANG= LC_COLLATE="C" LC_CTYPE="C" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL=    

found the solution: set it in /etc/launchd.conf
 
setenv LANG en_US.UTF-8 setenv LC_ALL en_US.UTF-8

This works like a charm.  Thanks for the help.  One thing to note in the paste of code in my line above I accidentily added the osascript line a second time at the bottom.  The real code should look like:
extract the filename from a full path filename=$(basename "{query}"); # set the new destination newpath=`osascript -e 'set theFolderAlias to choose folder' -e 'set theFolder to (the POSIX path of theFolderAlias)'` destination="$newpath/$filename"; # move the file mv "{query}" $destination; # open it open $destination;