PDA

View Full Version : full path in scripts


Octagon
08-18-2004, 08:45 AM
hi there,
while I havenīt paid attention to support full paths for any scripts I did in the past I would like to be in the future. But as it seems it is quite hard to really keep track of full paths in scripts where you do parenting and such or other operations that alter the full path of a dag node.
What I have now is a proc that constructs a full path based on a new parent for a given dag node. But calling this proc everytime after I change parenting seems a bit messy in terms of code-readability.
So how do you do it?

-matthias

mark_wilkins
08-18-2004, 05:41 PM
So how do you do it?
Why not use

ls -long <node>

to find the full path? I'm not sure why you have to write your own proc to do this.

-- Mark

Octagon
08-18-2004, 10:29 PM
Because ls -long can only give you a long path if the dag node that you pass to it is unique.
If the node you want to list using the -l flag is non-unique you need to give ls the full path or there will be an error (Maya cannot decide which of the non-unique nodes you want to list)
ls -l is a sick programmer's joke in my opinion unless I miss a few obvious things.

-matthias

mark_wilkins
08-18-2004, 10:46 PM
Because ls -long can only give you a long path if the dag node that you pass to it is unique.
If the DAG node is not unique, how do you specify it for your function? You must be doing something like parent|child, but that will work with ls -l as well.

-- Mark

macaroniKazoo
08-18-2004, 11:02 PM
i must admit i probably don't pay as much attention to getting full object path names workign with my scripts either. but generally speaking, it doesn't matter whether a variable contains a full path to an object or not. always work with full paths, and when you need just the obejct name, use:

string $objPath = "parent1|parent2|child";
string $obj = `match "[^|]+$" $objPath`;

so its pretty easy getting an object name from a path. its just a bit of a pain writing out the match string with all those weird characters. :) tends to break my typing speed...

so what problems specifically are you having working with paths? BTW `ls -sl` returns object paths automatically if the names aren't unique, but not all commands do (listRelatives doesn't).

Octagon
08-19-2004, 01:18 PM
If the DAG node is not unique, how do you specify it for your function? You must be doing something like parent|child, but that will work with ls -l as well.

-- Mark

For my proc in order get the full path of a non-unique node I specify the first unique dag node in its full path.

For example, for two hierarchies like

hrc1: joint1|uniqueJoint|joint3|joint4|myDagNode
hrc2: joint1|joint2|joint3|joint4|myDagNode

you could get the full path for myDagNode (the one in hrc1) by calling my code:

string $fullPath = `mzGetDagPath "uniqueJoint" "myDagNode"`;

This seems to be better than to use ls -l for that because you only need to know the one dag node that's unique to the hierarchy containing myDagNode. Using ls you need to have a lot more knowledge about the hierarchy. Call with ls would be as follows:

string $fullPath = `ls -l "|uniqueJoint|joint3|joint4|myDagNode"`;

Octagon
08-19-2004, 01:27 PM
string $objPath = "parent1|parent2|child";
string $obj = `match "[^|]+$" $objPath`;

so its pretty easy getting an object name from a path. its just a bit of a pain writing out the match string with all those weird characters. :) tends to break my typing speed...


Hehe, it doesn't slow you down if you make a proc out of it :)

I'm not having _specific_ problems with full paths but as I said in my previous post, it's not comfortable at all to do full paths and it bloats up the code quite a bit (instead of just working with obj names you are constanty switching between using path names and obj names)

I guess my policy for the future will be to only use full paths when they're really necessary. :hmm: Thanx by the way for the listRelatives issues, didn't know that (shame on alias)

-matthias

CGTalk Moderation
01-18-2006, 11:00 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.