|
From: Leo B. <lb...@br...> - 2002-10-12 01:27:14
|
Andy Bruce (AB...@ap...) wrote: > Sorry to interject--but beware of append_path, set_path, and > prepend_path. I spent some time putting in support for embedded > spaces (easy) and trying to "auto-magically" support differences > between "c:\" and "/cygdrive/c" formats (problematic at best). Andy Bruce (AB...@ap...) wrote: > Sorry to interject--but beware of append_path, set_path, and > prepend_path. I spent some time putting in support for embedded > spaces (easy) and trying to "auto-magically" support differences > between "c:\" and "/cygdrive/c" formats (problematic at best). Hello, Andy. Goodness, it's a mailing list with a voluntarily captive audience. No apologies required -- discussion is always welcome. :-) What's problematic about the *-path statements? The only issue I've ever run into with their use is when multiple modulefiles want to add the same information to a given env var. I've used some Tcl code to manage that, but I've never seen these routines do anything they shouldn't. > During this port I did some perf testings on append_path/set_path/ > prepend_path vs. pure-TCL, fully expecting it to be much faster > than, say: setenv PATH "$env(PATH):some_new_path" > > After all--it's compiled C code. > > However, it was not faster. It was measurably slower than using > the all-TCL code listed above. (Sorry, I don't have the numbers > anymore, but I could redo the test if there's interest.) Wow, was that causing you any problems? We use a project modulefile to in turn load a dozen other modulefiles, and I can load, unload or switch these out in a couple of seconds. Just curious what sort of magnitude of delay you were running into; I've never even thought about modules being slow thus far. Regards, - Leo Butler |
