Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ The working directory with scripts
|
The working directory with scripts
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Tue 09 Feb 2010 09:20 AM (UTC) |
| Message
| 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. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| Worstje
Netherlands (899 posts) Bio
|
| Date
| Reply #1 on Tue 09 Feb 2010 10:00 AM (UTC) |
| Message
| 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. :)
| | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #2 on Tue 09 Feb 2010 10:21 AM (UTC) Amended on Tue 09 Feb 2010 10:22 AM (UTC) by Twisol
|
| Message
| 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. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| Worstje
Netherlands (899 posts) Bio
|
| Date
| Reply #3 on Tue 09 Feb 2010 11:00 AM (UTC) |
| Message
| 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. | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #4 on Sat 13 Feb 2010 10:44 PM (UTC) |
| Message
| Hey, in regards to $PLUGINDIR and the like, is there any way to define those as DTD entities? Like:
<!DOCTYPE muclient
[
<!ENTITY PluginDir $PLUGINDIR>
]>
|
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #5 on Sat 13 Feb 2010 11:32 PM (UTC) |
| Message
| | $PLUGINDIR is dynamically evaluated (by Load_One_Include_XML) not when the XML is being parsed, so I think not. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
19,273 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top
