Hi Jep, Not in front of Nuke now, but from the looks of it, everything after "Moving on..." is indented within the except block.
Try de-denting it so it's outside of the try/except blocks. As for silencing all the error outputs, you could try to temporarily redirect sys.stdout and/or sys.stderr to os.devnull. But I have a feeling that by the time you're running "nuke -t" it might be already too late for that. Are you by any chance using Nuke 8? This should be easier to address by importing the nuke module directly instead of running "nuke -t" On Sun, Jan 26, 2014 at 12:25 PM, Jep Hill <[email protected]> wrote: > Thanks for checking me on this guys. Ivan, I am getting the same print out > now... the runtime exception does indeed work. I realized I hadn't tested > it properly -- DERP. > > the "print nuke.allNodes()" was just a quick test call I threw in there -- > in my code, I was actually running a block that included > "nuke.selectConnectedNodes()" -- that spits out an unbelievable amount of > junk when run on a script with "issues" -- any one know how to suppress all > that garbage when run via shell? We should be able to run that in "quiet" > mode. > > Ivan, can you confirm you're getting the same behavior with > nuke.selectConnectedNodes when running your "gizmos missing" script through > something like: > > ##### process2.py ########## > 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... > > activeWrites = [ x['selected'].setValue(True) for x in > nuke.allNodes('Write') if not x['disable'].value() ] > > if activeWrites: > > nuke.selectConnectedNodes() > files = list(set([ x['file'].value() for x in > nuke.selectedNodes('Read') ])) > > print "\n%s\n" % '\n'.join(files) > > if __name__ == '__main__': > main() > ###################### > > > nuke -t process2.py missing_gizmos.nk > > > It may be that this behavior is just inherent with the > nuke.selectConnectedNdoes method -- the larger issue I'm looking to solve > (lot's of posts on this issue -- not sure what the latest conventional wisdom > is as of 2014) > > > Basically, I'd like to optimize selectConnectedNodes to be able to find out > the files *actually used* by the active (non-disabled) write nodes to replace > a "tree walker" which is very slow. Ultimately I'd like to implement a > solution OUTSIDE of nuke that just parses the script file however, the .nk > file leaves no clues (that I've found) that would suggest which Read nodes > are actually used in any of the script trees. Since a shell based parse > doesn't seem to be an option, and python seems overly slow, perhaps C++ is a > better route to take? > > > Thanks again... > > > 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
