Gammon Forum : MUSHclient : Bug reports : The working directory with scripts

Log on

Gammon Forum

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. :)

Please see the forum thread: http://gammon.com.au/forum/?id=7224.

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 (22,975 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.

16,213 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.