I forgot to mention that you need to chmod +x yourfilename.command to
make it executable... otherwise osx wont "launch" anything.
What I like about the .command file structure is that you can already
set variables according to some simple if then rules...
we are having local raids for example in some machines so we check for a
specific folder to set the disk cache accordingly via the NUKE_TEMP_DIR
variable...
-johannes
Am 12/18/11 9:08 PM, schrieb Michael Garrett:
As Nathan says, I would have thought putting everything in the
.bash_profile would be a good way to go here. So you open a new shell
in Terminal and SSH in and you're done. I could be missing something
though because I haven't worked in a multi user OSX situation for a
while.
Johannes' solution of using a .command sounds interesting since it
seems you only have to edit that single file on the server instead of
updating .bash_profiles for each user (which probably isn't that hard
anyway).
On 18 December 2011 09:59, Deke Kincaid <[email protected]
<mailto:[email protected]>> wrote:
I believe only bash sees the environment.plist. The only way to
get everything to see an env variable on osx is to put it in launchd.
-deke
On Saturday, December 17, 2011, Nathan Rusch
<[email protected] <mailto:[email protected]>> wrote:
> I think Diogo's on the right track. I'm not an OSX guru, but
from some cursory Googling, it appears that the environment.plist
file is really only recognized by the Terminal application. Once
you ssh into something, you're out of that app, so the special OSX
rules no longer apply.
>
> According to this link
(http://snippets.dzone.com/posts/show/586), it looks like you may
need to set up some script or logic to parse the
environment.plist, and then run that script from your
~/.bash_profile (assuming you're using Bash).
>
> However, I would probably go one step further and say ditch the
environment.plist, and instead opt for setting up your shell
environment purely via ~/.bash_profile or some other more
"standard" approach.
>
> Hope this helps.
>
> -Nathan
>
>
> From: Diogo Girondi
> Sent: Saturday, December 17, 2011 11:59 AM
> To: Nuke user discussion
> Subject: Re: [Nuke-users] terminal launch via ssh
>
> Perhaps the ssh session is bypassing the environment.plist
somehow. I honestly don't know.
>
> When you ssh into that machine you use the same user as the one
where you have the environment.plist set? I ask because I have no
idea how this works.
>
> What you can do is run a export NUKE_PATH="path" before lauching
Nuke via ssh and see if that fixes the problem you're facing.
>
> On Sat, Dec 17, 2011 at 5:20 PM, Gary Jaeger
<[email protected] <mailto:[email protected]>> wrote:
>
> Thanks Diogo. That's what so odd. We have the environment.plist
all working, and all the volumes are mounted etc etc. I just have
no idea why using ssh would behave differently than actually
sitting at the machine. i.e. we're not having trouble getting nuke
to launch and see the plug-ins in normal operation.
>
> So the following (physically sitting at the machine) works:
>
> gfx08$ /Applications/Nuke6.3v5/Nuke6.3v5.app/Nuke6.3v5
>
> but this (sitting at the machine next to it using ssh) does not:
>
> gfx11$ ssh gfx08@gfx08
> Password:
> Last login: Fri Dec 16 09:39:45 2011
> gfx08:~ gfx08$ /Applications/Nuke6.3v5/Nuke6.3v5.app/Nuke6.3v5
>
> what could possibly be different??
>
> On Sat, Dec 17, 2011 at 10:56 AM, Diogo Girondi
<[email protected] <mailto:[email protected]>> wrote:
>
> On OSX I usually add a Apple script app to the user login items
that mounts the necessary volumes quietly on startup and then I
use a another Apple script to launch Nuke.
>
> To auto mount the volumes:
>
> tell application "Finder"
> try
> mount volume "smb://Lola/ToolBox/"
> on error
> display dialog "Lola wasn't there, come back later."
> end try
> end tell
>
>
> To launch nuke:
>
> do shell script "export
NUKE_PATH='/Volumes/ToolBox/Nuke';'/Applications/Nuke6.3v5/Nuke6.3v5.app/Nuke6.3v5'"
>
> But you can easily replace this last one for a environment.plist
saved on .MacOSX/ pointing to the Nuke path.
>
> O the renderfarm Qube was running similar commands before
starting a nuke render and the volumes were being auto-mounted by
Linux on startup.
>
> But there are probably better ways to approach this.
>
>
> Cheers,
> Diogo
>
>
>
> On 17/12/2011, at 15:56, Gary Jaeger <[email protected]
<mailto:[email protected]>> wrote:
>
>> /Applications/Nuke6.3v5/Nuke6.3v5.app/Nuke6.3v5
> _______________________________________________
> Nuke-users mailing list
> [email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
>
>
> --
> Gary Jaeger // Core Studio
> 249 Princeton Avenue
> Half Moon Bay, CA 94019
> 650 728 7060 <tel:650%20728%207060>
> http://corestudio.com
>
> _______________________________________________
> Nuke-users mailing list
> [email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/l
>
> ________________________________
> _______________________________________________
> Nuke-users mailing list
> [email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
