On Jan 14, 3:10 pm, Michael <[EMAIL PROTECTED]> wrote: > 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.
Here's what I was thinking when I wrote the arguments array in the shell: The idea is that these are the arguments to the script, thus arguments[0] is the first argument to the script. Note that the -f option to the shell permits multiple script filenames to be executed on a single shell session, so just looking at the first argument to the shell wouldn't be sufficient anyway. --Norris _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
