Ability to run bash AND a script for Script Filter and Run Script

[Matthew Lancellotti]

Currently there are some issues with Run Script when using /usr/bin/php, /usr/bin/perl, /usr/bin/python, etc...

 

Those processes are launched from the shell using certain environment variables (such as LANG=C or another non-unicode supporting environment) which disable features or environments we may need to run our scripts correctly.

 

Currently the only solution to this would be to use /bin/bash or /bin/zsh and set things ourselves and then launch our script from there.  Doing so means we sacrifice the convenience of having scripts right in the workflow visual themselves AND we can no longer take in the query conveniently.  We must now take in the query through bash for example, which is quite tricky (an experienced programmer may be ok, but just try taking in something like She said, "He said, 'this is fantastic!' ", and you'll see things are much worse than what is apparent).

 

 

 

 

To save us from this mess, we could have a vertical dual pane Run Script, where the top pane is a bash or zsh, and the bottom one of the script languages.  Users can then easily set any setup variables they need to make things run smoothly.  

 

Thanks kindly,

Matthew

[deanishe]

There are no problems passing arguments through bash as long as you set the Escaping options correctly ("Backquotes", "Double Quotes", "Dollars" and "Backslashes" only) and enclose {query} in double quotes, i.e. "{query}".
 
In any case, using bash still won't set your environment as you want unless you source ~/.bashrc. And what do you do with folks who use zsh or don't use Terminal at all and don't have a meaningful .bashrc? (/etc/bashrc doesn't set LANG or LC_CTYPE.)
 
This isn't an Alfred problem: it's simply the way UNIX works. Applications on OS X are started by launchd (unless you launch them from a shell) and, like programs launched via cron, init or upstart on Linux, they have an empty environment.
 
If your script needs an environment with LANG set or LC_CTYPE set to something other than C (LC_CTYPE is what you want to change if it's a text-encoding thing), then you'll have to set it explicitly yourself.
 
If you don't intend to share your workflow with anyone else, the simplest solution might be to launch Alfred from a bash script that sources ~/.bashrc and then launches /Applications/Alfred 2.app/Contents/MacOS/Alfred 2, instead of via the usual Login Items. This will ensure that Alfred inherits your full shell environment.
 
If you want a portable (to other users) solution for LANG, use defaults read -g AppleLanguages, grab the first result, replace the hyphen (if there is one) with an underscore, and append .UTF-8.
 
Here's a Python function from my Relative Dates workflow that gets the user's default language:
 

def get_default_locale():
    """Return system language"""
    output = subprocess.check_output(['defaults', 'read', '-g',
                                      'AppleLanguages'])
    output = output.strip('()\n ')
    langs = [s.strip('", ').replace('-', '_') for s in output.split('\n')]
    if not len(langs):
        raise ValueError('Could not determine system locale')
    return langs[0]

Note: it's called get_default_locale() because it's the locale I'm interested in, but getting the actual system locale (via defaults read -g AppleLocale) often provides values that Python doesn't understand, e.g. en_IT for a user with region set to Italy but system language set to English.

Edited January 5, 2015 by deanishe