Running a (no-AppleScript) script directly in Quicksilver

[lopmenhed]

I've written a bunch of Python scripts that I use periodically while at my computer and would like to be able to launch them from Quicksilver. I know that I can do either of these:

• Find a script in the first ("Item") box and select "Run a Shell Script" as an action
• Write an AppleScript that does something like do shell script "~/anaconda/bin/python ~/bin/foo.py"

If I simply select "foo.py" in the Item pane and then use the Open action, it doesn't work. This is what I'd like to be able to do, and even better I'd like to be able to specify arguments for the command.

I haven't found much on the about this topic, but here is a discussion from 2008 that looks like it's about doing the same in Ruby. I haven't been able to get their solution to work, either with the Ruby code from the discussion or with my Python translation of it:

#!/Users/kuzzooroo/anaconda/bin/python

import random, os
fname = os.path.expanduser("~/Desktop/test_") + str(random.randint(0, 65536))
with file(fname, 'a'):
    os.utime(fname, None)

The she-bang on this script is correct, I've given myself execute permissions on it, and it works from the command line.

[1.61803]

On Sunday, March 30, 2014 7:09:57 PM UTC+2, lopmenhed wrote:

I've written a bunch of Python scripts that I use periodically while at my computer and would like to be able to launch them from Quicksilver. I know that I can do either of these:

• Find a script in the first ("Item") box and select "Run a Shell Script" as an action
• Write an AppleScript that does something like do shell script "~/anaconda/bin/python ~/bin/foo.py"

If I simply select "foo.py" in the Item pane and then use the Open action, it doesn't work. This is what I'd like to be able to do, and even better I'd like to be able to specify arguments for the command.

You could adapt Run command in shell with arguments applescript action to suit your needs, I guess. 

[lopmenhed]

Thank you, 1.61803. But do you have a specific suggestion about how this might help? I'm unable to see how it fits in.

[Rob McBroom]

On 30 Mar 2014, at 13:09, lopmenhed wrote:

If I simply select "foo.py" in the Item pane and then use the Open action,
it doesn't work. This is what I'd like to be able to do, and even better
I'd like to be able to specify arguments for the command.

In general, the Open action is equivalent to double-clicking the file in Finder or running open foo.py from Terminal. So if you can get that to execute the script, Quicksilver should, too.

I wouldn’t screw with the behavior of Open though. There are already actions that can take care of this. “Run […]” will run the command and select the results as text in Quicksilver. “Run in Terminal […]” will open a new Terminal window and run the command there. I think that also works if you’re using iTerm. In all cases, you can optionally type arguments in the third pane.

(Note that passing arguments from the third pane is currently absolutely broken, but a fix should be released very shortly.)

#!/Users/kuzzooroo/anaconda/bin/python

import random, os
fname = os.path.expanduser("~/Desktop/test_") + str(random.randint(0, 65536))
with file(fname, 'a'):
  os.utime(fname, None)

The she-bang on this script is correct, I've given myself execute
permissions on it, and it works from the command line.

I tested that script with both #!/usr/bin/python and #!/usr/bin/env python using the “Run […]” action and it worked.

If you just want this action to be easier to get to, you could try dragging “Run […]” up above “Open” in Preferences → Actions. That should make it appear by default for executables, but since it doesn’t apply to other files, it shouldn’t interfere with normal file behavior.

--
Rob McBroom
http://www.skurfer.com/

[1.61803]

On Monday, March 31, 2014 12:35:50 AM UTC+2, lopmenhed wrote:

Thank you, 1.61803. But do you have a specific suggestion about how this might help? I'm unable to see how it fits in.

on open files -- instead of process text

do shell script "/usr/bin/python " & command

and the necessary adjustments.

But it seems that Rob's suggestion works by itself. So I would stick to the builtin action.

[lopmenhed]

OK, thank you both. For posterity: `#!/usr/bin/env python` did not work for me, but providing the full path to Python did.

[Daniel]

Aha! Looks like you've installed Python...maybe using a version manager? Not familiar with Python tooling. Somewhere other than /usr(/local)/bin, though. GUI apps don't pick up changes to your PATH that you make in .bashrc/.profile/etc. So when QS executes /usr/bin/env python, what env finds is /usr/bin/python, and PYTHONPATH and all the other associated variables are also not set/set to their system defaults.

In Snow Leopard, you could fix this by creating a file `~/.MacOSX/environment.plist`, a dict of VAR_NAME -> 'value'. That no longer works, and unfortunately there's no longer a way to do it per-user at all. What you can do is edit /etc/launchd.conf—plain text file, syntax is `setenv VAR_NAME value`. This will apply to the entire system, though, so be at least a little cautious of putting things ahead of the normal PATH, which is what you'd need in this case. (I do it, but there are certainly dangers.)

If QS is the only application you care about this for (but it's often not—any IDE or other tool that can run scripts probably wants the same envvars as your shell as well), you could also make a script, shell, Apple or otherwise, that launches Quicksilver after manually setting the PATH. As long as QS is launched with this script, it will have the right PATH and shell scripts will work. (Google `appify.sh` for how to turn such a script into an "application" that will work correctly if you add it to your login items.)

Extending this slightly, if most of the apps that matter are launched manually, after you log in, you could have launchd run a script on login that turns back around and calls `launchctl setenv VAR val...`. Any apps already launched won't be affected, though, and launchd does stuff in undefined order. Although there are ways to semi-force it to do stuff in order, so maybe...

Caaaaan you tell I've dealt with this before? :/ environment.plist really was a near-perfect solution, I don't know why it was removed. Hope the above is helpful.

[lopmenhed]

Daniel, you are right that I've installed my own copy of Python, in my case as part of Anaconda, a popular Python distribution that comes with a bunch of libraries and an IDE.

I think you have diagnosed the issue with /usr/bin/env python accurately. When I run type python from a terminal window I get the desired (Anaconda) path, but when I run M-x shell in Emacs and then run type python from the shell buffer I get the default /usr/bin/python.

Sounds like launchd.conf may be the only comprehensive solution. However, apparently launchd does not do any parameter expansion so I cannot do something like

setenv PATH /Users/lop/anaconda/bin:$PATH

Is there a way I can avoid having to hardcode my entire PATH (or whatever the PATH should be at this point in initialization)? This seems fragile:

setenv PATH /Users/lop/anaconda/bin:/everything/else:/even_more/

BTW, while researching this I stumbled onto EnvPane which seems to provide a nicer interface for launchd.conf for per-user settings. However, I don't see a way to handle parameter expansion there either.

[Daniel]

> Is there a way I can avoid having to hardcode my entire PATH

Not that I know of. Personally I do just hard-code the entire PATH, and while I agree it's a god-awful ugly hack, realize that if we can't figure out how to add stuff to the global PATH other than to hard-code it, *neither can anybody else* other than Apple. So it really ought to be reasonably safe, since the only time Apple is likely to change the default global PATH is during a major OS update, and said major updates wipe out /etc/launchd.conf. (Make backups, as a result!)

I have to suggest, though—I know the QS devs don't want to change the *default* behavior of the "Run" action, but might it be possible to have a spot in the preferences to define environment variables that should apply to commands run by Quicksilver? TextMate and other development tools, for instance, have a tendency to have this.

[Rob McBroom]

On 7 Apr 2014, at 18:52, Daniel wrote:

I have to suggest, though—I know the QS devs don't want to change the default behavior of the "Run" action, but might it be possible to have a spot in the preferences to define environment variables that should apply to commands run by Quicksilver? TextMate and other development tools, for instance, have a tendency to have this.

Seems like a reasonable thing to add to the Terminal plug-in. Someone should open an issue or it will be forgotten.

https://github.com/quicksilver/Quicksilver/issues

[Daniel]

Done, #1819. Not sure it's specific to the Terminal plugin, though, as detailed in the issue. It could start there, though—sounds like that would solve lopmenhed's problem, and I just use launchd.conf and deal with the fallout.

[Rob McBroom]

On 8 Apr 2014, at 22:47, Daniel wrote:

> Not sure it's specific to the Terminal plugin, though, as detailed in
> the issue.

Maybe not, but if you’re the sort of person that knows what
environment variables are and wants to customize them, you’re probably
the sort of person that has the Terminal plug-in installed. :-)

And that lets us keep the main prefs a little cleaner for everyone else.

[Daniel]

I just meant that it should affect actions which the Terminal plugin does not provide, so it might be ugly to have core support for it be part of the plugin. Depending on how powerful QS's plugins are that may not be an issue, and I certainly agree that from a UI standpoint having it sectioned off with the other Terminal stuff is probably a good idea.

Honestly I feel like it would ultimately make sense to split the plugin in two, with "Scripting Support" or something being analogous to the "Email Support" plugin, and then the Terminal (and iTerm) plugins only providing the actions and functionality that specifically interact with those applications. It seems in one sense silly to have to have the Terminal plugin installed when I only use iTerm. But that's another story.

[Rob McBroom]

On 9 Apr 2014, at 22:18, Daniel wrote:

Honestly I feel like it would ultimately make sense to split the plugin in two, with "Scripting Support" or something being analogous to the "Email Support" plugin, and then the Terminal (and iTerm) plugins only providing the actions and functionality that specifically interact with those applications. It seems in one sense silly to have to have the Terminal plugin installed when I only use iTerm. But that's another story.

It actually does work that way, with QSTerminalMediator handing the work off to either Terminal or iTerm. The difference is that, unlike E-mail Support and Chat Support, the Terminal mediator was never given a dedicated plug-in. It’s included with the Terminal plug-in, which is why the iTerm one requires it.

It should eventually be split out, but I can’t say that’s at the top of anyone’s list. Care to take a crack at it? :-)