From: Gary Jaeger <gary@(email surpressed)>
Subject: Re: nuke renders with central tools
   Date: Tue, 20 Dec 2011 09:46:04 -0500
Msg# 2172
View Complete Thread (10 articles) | All Threads
Last Next
Great answer as usual Greg. Thanks. 

I think the /usr/bin idea is the best. One of my overall goals is to cut down on the manual work to do every time I want to deploy a plug-in or a new version of nuke comes out. Doing the /usr/bin thing would take care of that as well as ensuring I don't also have to modify my nuke submit every time.

On Dec 20, 2011, at 5:22 AM, Greg Ercolano wrote:

Perhaps what you want to do to solve the issue for 'everyone'
is to make a nuke 'wrapper' script called /usr/bin/nuke
that sets the enviro...

Or, have the above script simply run a script on your server
so that you can centrally manage the variable settings, and not
have to update all /usr/bin/nuke scripts whenever you want to
make a small change to the script. eg:

#!/bin/sh
exec /Volumes/somewhere/nuke "$@" # <-- quotes important around $@

Whatever you do, DON'T do the seemingly obvious thing
by making /usr/bin/nuke a symlink to the script on your NFS
server....

OK, but what we *could* do is make a Mac alias to that file and put it in the Dock, so freelancers and employees could simply go to the dock as usual and click or double click. I'll have to decide which route to go. 

As I side note, I do notice *slightly* different behavior on quit between the two methods. If I just type nuke in the terminal, then hit Cmd-Q in the resulting GUI the terminal returns to normal. If I double click an alias to that file, then hit Cmd-Q in the resulting GUI the terminal, the terminal stays with 

[Process completed]

displayed and never gets back to the prompt (is that the right term?) anyway sort of interesting. 

Thanks again Greg.

Gary Jaeger // Core Studio
249 Princeton Avenue
Half Moon Bay, CA 94019
650 728 7060


Last Next