Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, 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.
Entire forum
➜ MUSHclient
➜ Suggestions
➜ Force current directory to be the exe location for world loading
|
Force current directory to be the exe location for world loading
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
| Date
| Thu 10 Feb 2022 05:59 AM (UTC) Amended on Thu 10 Feb 2022 06:10 PM (UTC) by Fiendish
|
| Message
| If you have a world in your Load at Start list with a relative path, say “./worlds/Aardwolf.mcl” that contains within it more relative paths, and you launch MUSHclient from the command line from a different location,
example:
MUSHclient/MUSHclient.exe
instead of
cd MUSHclient
MUSHclient.exe
An error dialog pops up saying that the (relative path) world file contains an invalid path.
If you then go to File->Open Worlds in Startup List, a different error dialog pops up saying that the (absolute path) world file contains an invalid path.
It’s weird that the errors are not the same (that one shows the relative path and one shows the absolute path), but I think it would be superior for all cases if, when loading world files, relative paths were always interpreted from the executable location and not from wherever the user happens to be in their file system.
|
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
| Date
| Reply #1 on Thu 10 Feb 2022 11:28 AM (UTC) |
| Message
| Hmm. Well, it would be better behavior, but lets be honest, having it treat the executable location as the default is non-standard on Windows. There is a reason why almost 100% of all application use either a branch of "application data", or "documents" as a save location - because it guarantees that data that can/needs to change is always written some place that doesn't have write restrictions on it, and gives a standard location for all data, so you can, in theory, always find it.
This is even why its often suggested you don't install Mushclient, in all cases, in the normal program locations - because it never has conformed to this behavior, and doesn't apply sensible rules.
That said.. Yeah, it would be better if there was a clear, built in, rule for this, instead of the program "guessing". | | Top |
|
| Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
| Date
| Reply #2 on Thu 10 Feb 2022 06:06 PM (UTC) Amended on Thu 10 Feb 2022 06:11 PM (UTC) by Fiendish
|
| Message
|
Quote:
having it treat the executable location as the default is non-standard on Windows.
That's actually false for most things. Consider how MUSHclient never fails to find its Lua DLL. I promise that it's not because it stores the DLL in application data or documents.
Quote:
There is a reason why almost 100% of all application use either a branch of "application data", or "documents" as a save location - because it guarantees that data that can/needs to change is always written some place that doesn't have write restrictions on it
That's a nonsequitur. My suggestion has nothing to do with write restrictions.
I'm talking exclusively about how relative paths are written and interpreted. If you want to use absolute paths to documents, feel free, but relative paths must be both recorded and interpreted relative to a concrete reference or else they are guaranteed to break. Having that concrete reference be arbitrarily outside of MUSHclient's space is just bad. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Sat 12 Feb 2022 06:44 AM (UTC) |
| Message
|
Quote:
If you have a world in your Load at Start list with a relative path, say “./worlds/Aardwolf.mcl” that contains within it more relative paths, and you launch MUSHclient from the command line from a different location,
example:
MUSHclient/MUSHclient.exe
instead of
cd MUSHclient
MUSHclient.exe
Let's say I am using the command line (shell) prompt in Linux, and my current directory is /home/nick and in that file is an image I want to edit, such as cat.png.
I might type:
Now I expect my "current directory" to stay the same, and not change to /usr/bin/ because if it did, it wouldn't find my cat image. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
| Date
| Reply #4 on Sat 12 Feb 2022 06:47 AM (UTC) Amended on Sat 12 Feb 2022 06:48 AM (UTC) by Nick Gammon
|
| Message
| |
| Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
| Date
| Reply #5 on Sat 12 Feb 2022 06:38 PM (UTC) Amended on Sat 12 Feb 2022 06:47 PM (UTC) by Fiendish
|
| Message
|
Nick Gammon said:
Let's say I am using the command line (shell) prompt in Linux, and my current directory is /home/nick and in that file is an image I want to edit, such as cat.png.
I might type:
Now I expect my "current directory" to stay the same, and not change to /usr/bin/ because if it did, it wouldn't find my cat image.
This is not the same because gimp doesn't have its own portable internal storage directories like MUSHclient does. If you tell your command line /usr/bin/gimp cat.png, your computer gives gimp /your/current/path/cat.png. Gimp is not actually using a relative path for your file. It doesn't need to.
MUSHclient on the other hand is structured to be portable and has internal standard directories for the user's sounds, plugins, lua imports, etc. But the only way to make MUSHclient actually portable (and in my case redistributable) is to use relative paths, and using relative paths breaks on this issue.
MUSHclient reading a world file in the standard world files folder that says that sounds are in the standard sounds file folder* shouldn't break when the user runs MUSHclient/MUSHclient.exe instead of MUSHclient.exe
* - Just an example. I don't actually know which path it's complaining about because the error message doesn't say.
MUSHclient already successfully finds the world file. I'm asking for the same behavior to extend to inside the world file as well. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
| Date
| Reply #6 on Sat 12 Feb 2022 07:21 PM (UTC) Amended on Sat 12 Feb 2022 07:34 PM (UTC) by Fiendish
|
| Message
|
I don't want to resurrect that thread itself by commenting on it, so I'll put a brief response here:
Nick Gammon said:
Let's take an example. Two people use one PC. MUSHclient is installed in 'C:\Program Files\MUSHclient'.
However they start it in different directories (the intial or startup directory). For example, one might be 'C:\Files and Documents\Shadowfyr\MUSHclient' and the other one might be 'C:\Files and Documents\Marilyn\MUSHclient'.
The point of doing that is so that you can each have your own world files (and log files etc.).
Because of this you both open your logs in a relative '.\logs' directory.
Nobody does this. And I don't even mean because nobody is putting MUSHclient into Program Files anymore, though that's also part of why. The real reason that nobody does this is because the concept of a start directory is both extremely obscure and also very fragile and arbitrarily restrictive and breaks in circumstances like the one I outlined above.
What people in that scenario actually do now is just make their own independent MUSHclient folders, because they can do that now, so that they never have to fight over plugin or lua import name conflicts or desired client versions.
And if a person wants their logs to be somewhere outside of the MUSHclient folder, they have the ability to do so already without using relative paths that should definitely point inside the MUSHclient folder, because Windows has always had path variables for both user and current directories which they are free to use. |
https://github.com/fiendish/aardwolfclientpackage | | 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.
13,019 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top