[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  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] Refresh page

Posted by Fiendish   USA  (2,500 posts)  [Biography] 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
[Go to top] top
Posted by Shadowfyr   USA  (1,785 posts)  [Biography] 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".
[Go to top] top
Posted by Fiendish   USA  (2,500 posts)  [Biography] 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
[Go to top] top
Posted by Nick Gammon   Australia  (22,928 posts)  [Biography] 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:


/usr/bin/gimp cat.png


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
[Go to top] top
Posted by Nick Gammon   Australia  (22,928 posts)  [Biography] 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
Possibly relevant: https://www.gammon.com.au/forum/?id=9741

Also some discussion here: https://www.gammon.com.au/forum/?id=7776
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Fiendish   USA  (2,500 posts)  [Biography] 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:


/usr/bin/gimp cat.png


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
[Go to top] top
Posted by Fiendish   USA  (2,500 posts)  [Biography] 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
Nick Gammon said:

Also some discussion here: https://www.gammon.com.au/forum/?id=7776

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
[Go to top] 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.

9,065 views.

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

Go to topic:           Search the forum

[Go to top] 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.

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]