I think what Jep is trying to get to is not the fact that running nuke -t with a .py argument exits on completion, but the fact that it is exiting before the script gets a chance to run "print nuke.allNodes()", presumably due to a raised exception.
Jep, you could try to figure out exactly what exception is thrown before the script exits, and handle that exception yourself, as Jose suggested. For example, if it's a RuntimeError... (this is untested, but you get the idea) import nuke import os def main(): nk = os.path.abspath(sys.argv[1]) try: nuke.scriptOpen(nk) except RuntimeError: print "A RuntimeError occurred: Ignoring..." pass # Moving on... print nuke.allNodes() if __name__ == '__main__': main() On Sat, Jan 18, 2014 at 12:54 PM, Nathan Rusch <[email protected]>wrote: > If I understand what you're after, you want to start Nuke, run your Python > script, and then drop into an interactive Python session. > > The standard Python behavior when it receives a script argument is to > execute the script and then exit. However, with a normal Python > interpreter, you can add the -i flag when starting the process to tell it > to drop into interactive mode instead of exiting when the script finishes > executing. Unfortunately this won't work with Nuke because it A) doesn't > really function like a Python interpreter, and B) does all of its own > parsing of command-line flags. > > Thus, you are left with a couple of options: > > 1) If you're using Nuke 8, don't run Nuke; run the Python interpreter that > ships with it instead, as this will allow you to use the -i flag. > > 2) If you can't do that, the code method should work with the Nuke > process. Just add these lines to your script: > > import code > code.interact('-- Entering interactive mode --', local=globals()) > > > > -Nathan > > > -----Original Message----- From: Jep Hill > Sent: Saturday, January 18, 2014 12:30 PM > To: [email protected] > Subject: [Nuke-python] [nuke -t] oddness when opening scripts with > errorsin interactive mode > > > Thanks for the responses guys. > > Yeah, the reason I put the "try" block with a wide open exception was to > detect *any* issues... that keep the script from opening and prove that the > script is indeed failing to open... > > @Jose, agreed that it's best practice to avoid wide open exceptions :) > > @Michael, without the "try" block, I just get warnings and then kicked > back to the sh. > > So , if you do something like this: > > ### openTest.py > > import nuke > import os > > > def main(): > nk = os.path.abspath(sys.argv[1]) > nuke.scriptOpen(nk) > ### you'll never get past this point with buggy scripts... > print nuke.allNodes() > > if __name__ == '__main__': > main() > > ### end > > nuke -t openTest.py myNukeScript.nk > > Just shows errors and goes back to the prompt... BUT: > > nuke -t > nuke.scriptOpen("myNukeScript.nk") > ### doing this interactively in a shell works and allows me to operate -- > even on scripts with errors... > print nuke.allNodes() > > WORKS. > > The main point is that the pythonic approach should do the exact same > thing as the interactive approach I've shown above -- how can I get this? > > Cheers, > Jep > > > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
