The working directory with scripts

This is a recurring issue, from what I've seen. When running scripts in subdirectories of plugin/, or even plugins outside plugin/, the working directory remains in plugin/, which causes no end of frustration. This is particularly evident when using <include> tags. If I have an <include> tag, I assume that the path will be relative to the current file, not one single arbitrary folder.

Complex plugins using my "structured plugin" paradigm can and will hit this wall, as well as any other plugin that happens to store scripts and XML in a subdirectory for easier management. It's also undesirable to hardcode the plugin's directory name into the include path, because that may very well change or vary. Lastly (in my examples, at least), this makes it very difficult to group disparate plugins in subdirectories based on the MUD you use them with.


I have two suggestions to help fix this:

1. When processing XML files, change the current working directory to the location of the XML File. This counts for <include> files recursively as well, restoring the previous working directory after each file is processed.

2. When executing a script routine, change the working directory to the location of the main script file. In the case of plugins, this is the file that was Added in the dialog. In the case of worlds, this is the location of the world's script file.

This would make it infinitely easier to work with and organize plugins.

1. No.
2. No.

Why? You are breaking compatibility with old plugins. Yes, it is a bad way to design them, but never the less, old plugins depend on the behaviour as it is right now.

And not any less important, you are now forcing the Open/Save dialogs to be wherever you want them. (I fully agree they shouldn't depend on that stuff, but alas, they do.)

But there is GOOD NEWS, too!

The good news is I already brought up this issue some years back. And Nick implemented something that fixes your REAL problem, rather than the perceived one. :)

Well, okay, the $PLUGINDIR is excellent. It's still incredibly, incredibly annoying that you can't use require() to load files in the same folder, but have to hack around with dofile().

I have one more suggestion for the XML side of things: $XMLFILEDIR (or something similar), which refers to the current XML file's directory. That way, XML files which have themselves been included can still refer to files in their own directory.

EDIT: As for the Open/Save dialogs, I see absolutely no reason why they would change. The working directory would be saved and restored after the relevant action is completed, whether that be the loading of an XML include or the execution of a script routine. They would use the same previously-set working directory as before.

It is a side-effect from the Windows Open and Save dialogs that the working directory changes and is used as a remembering-point. You can work around it and all, yes, but it isn't how it is implemented in MUSHclient.

The working directory affects a lot of things, file loading, these dialogs, probably even more... changing it all around is a pain in the ass at this point since there will without a doubt be people who have plugins break and the likes.

Hey, in regards to $PLUGINDIR and the like, is there any way to define those as DTD entities? Like:

$PLUGINDIR is dynamically evaluated (by Load_One_Include_XML) not when the XML is being parsed, so I think not.