David, Attila: many thanks for your answers -- I really was starting to think I was just missing something obvious. Turns out I was missing something complex, so that makes me feel a little better :)
I wonder if anyone knows why I can't just grab the path to the executing file from the commandline arguments. I'm not sure how the commandline arguments get handled but I was surprised to find that arguments[0] is actually not the first argument I passed to Rhino (which would be the path to the file to execute in my case), but rather the second argument _after_ the path to the file. Where did that first argument go? If I could get at it somehow I would be on my way. Regards, Michael On Jan 14, 9:41 pm, Attila Szegedi <[EMAIL PROTECTED]> wrote: > Yeah, we could add a feature for accessing the path of the current > script file from shell. > > Outside of shell, the concept of "path" is, as you correctly point > out, meaningless. A JavaScript runtime itself does not manage the > source code resources on its own, so it has no concept of a path, nor > that of an include, etc. A particular extension for a specific > embedding needs to define those - if it wishes - in an implementation > specific, proprietary manner. Like, say, HTML does with <script > src="..."> > > Attila. > > On 2008.01.14., at 19:50, David P. Caldwell wrote: > > > On Jan 14, 12:27 pm, Michael <[EMAIL PROTECTED]> wrote: > >> I am trying to find a way to reliably get the path to currently > >> executing script file, from within that same file. Reason for that is > >> I want to access some other files that I know are in the same > >> directory as the script file, but I can't predict what the current > >> working directory will be when my script is run. > > > I have wanted to do this in the past as well, but I am pretty sure you > > have to build this into your own embedding (or launch mechanism) if > > you want to do it. I don't use the Rhino shell much, but in my own > > embedding I've had to wrestle with this issue from several > > perspectives (and am thinking that a "module" loading strategy in > > which the entry point of the module is provided a context from which > > to load contained files is the next step after the series of ad hoc > > solutions I've used thus far). > > > There are good reasons you can't do it -- because it's legal to load > > code for Rhino from any Java Reader. As such, the Rhino codebase > > doesn't really have the concept of a "file" from which JavaScript code > > is loaded (it can also evaluate strings -- as you have probably seen > > from the shell, you can pass arbitrary code on the command line). So > > the question of which file JavaScript code was loaded from would not > > have a general answer and code from the file system would need to be > > handled as a special case. But what if you are (like many) using > > Rhino on the server side; clearly you'd like to be able to load code > > by relative path from other code, even though you didn't load it from > > a "file" (but rather a ServletContext). > > > So anyway, as I understand them, the issues here end up being more > > complex than one might think at first glance. > > > Others more familiar with the Rhino shell may have more to add. _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
