Copy to Clipboard not accepting special characters

[Matthew Lancellotti]

My workflow script ends with printing output.  That output goes to Alfred's "copy to clipboard".

 

 

 

1. How does Alfred interpret the output it receives?  Do I need to escape anything in my output?

 

Perl code:

print 'this is a string with special characters in it Đ⌂'

The above is a simplified model.  What is REALLY happening is the Perl code copies the special characters from the clipboard in the first place, then prints them out.  When I look at what the Perl code prints out in the terminal, I can see the special characters just fine.  So it seems that it is ALFRED who is unable to accept the special characters or put them into the pasteboard correctly.  It replaces them with '?' question marks.

 

 

 

2. I am open to creative solutions.  I never intended to copy my output to the clipboard in the first place.  I just needed to use the "paste into frontmost application" option.  Using an apple script to execute "cmd-V" is an option, but I don't think it will work in all applications.  I guess my second, slightly related question is "How does Alfred paste into the frontmost application reliably?"  Maybe I can mimic that behavior and bypass Alfred.

Edited November 8, 2014 by Matthew Lancellotti

[deanishe]

You need to make sure text you send to Alfred is UTF-8 encoded.

[Matthew Lancellotti]

Unfortunately, outputting in UTF-8 is not working.  The ⌂ character, which I copied from a website (HTML code ⌂), still causes question markiness.

 

The â character, on the other hand, causes the Alfred error:

[ERROR: alfred.workflow.action.script] Code 0: Wide character in print at VeryKiwiFilter.pm line 56.

My workflow grabs things from the clipboard, so I don't know how the input is coded.  Will the clipboard guarantee it is UTF-8?  Can the input be encoded in many different ways depending on what was copied?

 

But either way, the output still looks great in the terminal, but not in Alfred.  How can I further troubleshoot?

[deanishe]

That error looks to be coming from your script.
 
At a guess (I know nothing about Perl), I'd say the problem is due to your terminal using UTF-8 (i.e. you've set LANG=en_US.UTF-8 or similar). Alfred calls scripts with LANG=C (Cocoa apps all inherit the empty launchd environment) which means ASCII.
 
Try running your script via bash (set the language to bash in Alfred) and precede it with LANG=en_US.UTF-8 (or some other *.UTF-8 locale), e.g.:

LANG=en_US.UTF-8 /usr/bin/perl myscript.pm

[Matthew Lancellotti]

It doesn't make sense to me that Alfred would run my scripts in the LANG=C environment when there is something much better.  Is there a good reason for this?  Perhaps I will suggest a change to the company.

 

Thanks for the workaround.  It's messy but at least functional.

[deanishe]

I was wrong about the LANG value. It's actually empty. LC_COLLATE, LC_MESSAGES and others are set to C, however.
 
That's just how UNIX works. The default locale is C/POSIX (same thing). Linux does exactly the same thing if you start a process via cron or initd, which is what happens on OS X, too: the applications you start are actually started by launchd.
 
Unlike on Linux, the desktop environment isn't launched from a shell, so it doesn't inherit your shell environment.
 
If you start Alfred from a shell (open "/Applications/Alfred 2.app/Contents/MacOS/Alfred 2"), it does inherit your shell environment.

 
You can alter launchd's environment using, e.g. launchctl setenv LANG en_GB.UTF-8, and create a corresponding launch daemon if you want to permanently alter the environment (i.e. across restarts).
 
This is a bad idea if you intend to distribute your workflows to other users, however.

[Matthew Lancellotti]

Thanks for all the useful info, deanishe!

 

I found a simple solution, and it was to change the environment variable from within my script.  This is good because I don't have to take my query in through bash, and it will work wherever I distribute my workflow.

 

In Perl specifically, I used $ENV{LANG} = 'en_US.UTF-8'; at the beginning of my script.

 

My only question is, will non-US users have the en_US.UTF-8 environment?

[deanishe]

Yeah. OS X includes all locales supported by the system by default.
 
Run locale -a in a shell to see a list.