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


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  Path bug...

Path bug...

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


Pages: 1  2 3  

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #15 on Wed 11 Apr 2007 11:12 PM (UTC)
Message
Quote:
Huh??? Oh, right, in the script. But that isn't the same bloody thing, and it would only do that if you did something absurdly silly, like not checking for the "C:". In other words, fixing it is a matter of doing what ever other application does in this case and assuming that, if you are in "c:\foo\bar", then "\logs\log.txt", "logs\log.txt" and ".\logs\log.txt" are **equivalent** and should produce "c:\foo\bar\logs\log.txt". Obviously "..\logs\log.txt" should produce "c:\foo\logs\log.txt". Howevery, something like "g:\bar\foo\logs\log.txt" is **not** a relative path in the first place, so its path should override any path information that is there and give you "exactly" that path. Sorry Nick, but I can't imagine why you would think that *any* application that uses relative paths would handle "g:\bar\foo\logs\log.txt" by making it "c:\foo\bar\g:\bar\foo\logs\log.txt". Mind you, I have seen at least one case where some fool did that in a program. It was fixed in the next version. lol

So what if my copy of MUSHclient is in "C:\Program Files\MUSHclient" and my startup directory is "C:\Files and Documents\Biggs\MC" and they both contain subdirectories and files identically named "\logs\log.txt" Not to try and shoot this idea down, but I'd just like to know what you think the program should do if I try to open up a file with ".\logs\log.txt"

Quote:
It makes no sense for it to be using a relative path based on where some completely different program last opened something.

Ok, this time I am trying to shoot down an idea. You do realize that the file picker Windows provides is a program, right? That's how you can click on "Explore current directory" in a lot of programs and have a window pop up with whatever directory is considered the "current directory" by said program. Occasionally these issues can collide with each other, especially on older programs designed for Win98 or earlier systems. Wine tends to get around this by storing the current directory slightly differently as far as I can tell, since I can't duplicate the issue you mentioned in the first post of this thread.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #16 on Thu 12 Apr 2007 12:45 AM (UTC)
Message
The other thing I want you to consider is that when you make a request like "please change the behaviour of the program to do X instead of Y" that a whole lot of people (maybe thousands) are relying on behaviour Y, and have written scripts expecting it.

For example, someone may have a script run at program startup that does a ChangeDir - quite deliberately, so that afterwards stuff (like logs) is in a relative path to the new directory.

To make the client override that and force relative paths to be relative to the executable (or the startup directory, you haven't said which you really mean yet), could make such scripts break.

http://www.gammon.com.au/scripts/doc.php?function=ChangeDir

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #17 on Thu 12 Apr 2007 01:14 AM (UTC)
Message
Well, with a combination of grabbing the startup directory, or the first working directory, and using ChangeDir, you can muck about with where you have the client pointing to wherever you want.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #18 on Thu 12 Apr 2007 07:43 PM (UTC)
Message
My only comment about the "expected" behavior you are talking about Nick is that ***its not reliable***, so if they are actually relying on it, they are seriously foolish anyway. The point it, its *not* reliable if you are basing your behavior on commands that can't remember and maintain a known directory location, from which to derive those paths. That's the whole problem to start with. I would really hope that scripts that use directory commands are using something more stable, otherwise its inevitable that the script **will** fail when something else changes the location. Personally, I would rather have "reliable" design, not backward compatibility.

What commands "in" a script that involve the "scripts" own functions are doing is one thing, what commands that are part of the client design do.. That is imho entirely different. Frankly, depending on how the io functions for the script system work, it might not even be reliable to expect *those* to produce the same results from moment to moment when using the clients file commands. Why not? Well, who is to say 5 different plugins won't all be using those io functions? Why cater to bad programming practice, instead of just saying, "relative paths are not reliable and can change unexpectedly, so if you want to open a file some place *other* than in one of MUSHclient's own directories, provide a 'complete' path. If you don't, it might not work correctly." Given the problems we already have with this, relying on the existing behavior is plain bad design. I am not talking about changing what the script does, just the stuff "in" the client, where I think everyone is likely to presume its relative to the program path. If some fool wants to play, "Lets hope the directory is right today!", with script io, more power too them. But I just don't see the benefit of ignoring reality and presuming its either good coding practice in a script (or any place else) or that it actually works now (it doesn't, it simply doesn't break often enough for people to *get* that it won't work like they think it does).

But heh, its your call, for now. Its not like I have scraped together the hundreds of dollars needed to try to fix it myself at this point. lol
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #19 on Thu 12 Apr 2007 08:53 PM (UTC)

Amended on Thu 12 Apr 2007 08:59 PM (UTC) by Shaun Biggs

Message
So out of curiosity, have you looked at the GetInfo function at all?
Quote:
(strings - calculated at runtime)

51 - Current log file name
52 - Last "immediate" script expression
53 - Current status line message
54 - World file pathname
55 - World title
56 - MUSHclient application path name
57 - World files default path (directory)
58 - Log files default path (directory)
59 - Script files default path (directory)
60 - Plugin files default path (directory)
61 - World TCP/IP address (as string, after DNS lookup, eg. 10.0.0.16)
62 - Proxy server TCP/IP address (as string, after DNS lookup, eg. 10.0.0.22)
63 - Host name (name of this PC)
64 - Current directory
65 - Script function for world save
66 - MUSHclient application directory
67 - World file directory

These values can be used to grab whatever you need. I don't see why we have to cater to bad programming practice either, such as not using available functions to get a defined path to your file rather than just going for the "current directory" which, being just "current", can change. By the way, all of my scripts, logs, etc are in C:\blah blah blah, and my current directory is "H:" and I have had no problems whatsoever with any of my scripts. Also, to fix issues with having hard file paths to plugins on my world file on my USB drive, I've made a script that's executed once the file is loaded that will grab the program directory and load the plugins with a relative path from there. Not terribly hard to do, and then I have a variable with the path I need stored.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #20 on Thu 12 Apr 2007 10:35 PM (UTC)
Message
Given that a script (or a DLL a script calls) might change the current directory without "notifying" MUSHclient, and given that another script might rely upon the current directory, I would have to say this:

Warning - do not rely upon using "relative paths" in MUSHclient.

In fact, in a recent script, I found exactly that problem, so I added a "ChangeDir" into an alias. See:

http://www.gammon.com.au/forum/bbshowpost.php?id=7764&page=2

That is:


ChangeDir (GetInfo (66))  -- make sure we are in MUSHclient executable directory

require "addxml"  -- addxml extension


I agree there is a problem, I'm not totally certain that your suggestion of "ignore the operating system" is the right solution.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #21 on Fri 13 Apr 2007 09:36 PM (UTC)
Message
Shaun, as I said, or tried to, several times, the issue isn't necessarily with script. You ***can't*** use "GetInfo" to set the location for opening a log automatically "in" the log settings, so the existence of such a command is worthless in that context. In the context of the World and other settings "in" MUSHclient, lets assume for the sake of argument that we don't even have/use scripts, it makes no sense for those settings to be using a relative path that is not associated with some known location. At the very least, one needs some way to make very clear that the "log" directory, in that context, ***is*** related to the program's own folder, not some arbitrary place that changes every time the system does something. Imagine for a moment if MUSHclient treated any other setting that way. Loaded worlds, its script engine, its spellchecker, its plugins, etc. from a "relative" path that was based on an arbitrary location, instead of the program path. Nothing would work. Therefor, it makes no sense that the relative path "in" the settings for log files should point at anything other than the one directly under the application path either.

If someone wants to open a log file or anything else based on a relative path that "isn't" in that path, let them do it in the script itself and suffer the logical consequences of that. But the "inbuilt" function for maintaining logs and opening them should imho, have a consistent "default path", which comes from the client, not the OS, since its the *client* that is handling the logs, not WinAmp, Explorer, Word, a database of your aunt's favorite cookie recipes *or* even the script system.

That's all I am saying here. I really don't care what the behavior is "in" the scripts. But it makes no sense for 90% of the functions for loading everything in through the client's internals to be based on a path relative to the client, but have logs inexplicably, when defined through the same, just try to open where ever the system happens to have last opened a folder. And GetInfo doesn't do anything to fix that, nor does the, "Use %L to have it open in the default log file path", make sense unless there is "really" a default of some sort, and not just where ever the system is looking at the time.

Someone wants to point the system at Z:\foo\bar and then do "openlog (".\logs\log.txt")", or what ever the command is in scripts for it, I wish them luck. But I don't think it makes any sense for the built in log management to presume that someone has, can or "will" set the path to the right place *before* opening one with the default log path. It just doesn't make any sense, either in context of a) what is being done or b) the description of the options for that log command.

Let me put it another way:

%L%N_%m-%d-%Y(%I-%M %p).txt - Program path.
.\logs\%N_%m-%d-%Y(%I-%M %p).txt - Where ever the system is currently pointing.

%L **implies** that the application already knows where that "is", the install already makes a folder (I think) by that name, so the logical conclusion is that, unless you specify otherwise by changing it, %L should be the application path + ".\logs\". Show me *any* application that supports such things that doesn't presume a default location based on "itself", instead of an arbitrary one, and which works right, and I will be happy to concede that the description of %L makes any sense at all the way it currently works.
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #22 on Fri 13 Apr 2007 11:16 PM (UTC)
Message
That still doesn't explain why anyone would persist in using relative path names when you know they don't work the way you expect them to work. It's generally poor practice to use relative paths when full paths are possible just do to the confusion that might happen. My log files for each world are set with a full path, since I know where I want my file to be. If I have something that can vary due to which world or user is using a plugin I've made, then I just have code set with OnPluginOpen to set it to a hard file name.

What's really so hard about putting "C:\Program Files\MUSHclient\logs\%N_%m-%d-%Y(%I-%M %p).txt" as a filename?

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #23 on Sat 14 Apr 2007 09:18 PM (UTC)
Message
Nothing it hard about doing that. The issue is, if we really get down to it, that how %L operates is imho misleading. I can't speak for everyone, but I suspect that most people when they read that it provides the, "log path", are going to look at the directory structure for Mushclient, see that there is a path like "c:\program files\mushclient\logs" and *assume* that this means that the default location for that path is going to be the application path + "\logs\", not some completely unknown location. Its confusing. And worse, when it doesn't open because it can't find a "logs" directory in what ever place it does try to open it, it fails silently, so that unless you notice that the log icon isn't active, you don't know it isn't saving one. This is, imho, very bad, regardless of what ever other arguments you made about what the correct behavior should be.
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #24 on Sat 14 Apr 2007 09:41 PM (UTC)
Message
Well, if you would care to notice... I don't use the "%L" because I don't want to deal with any type of dynamic link. I've said this in a few posts, and you still try to say that I'm arguing that it's a perfectly acceptable way to do things. All I'm saying is that you have declared something is a bug, you have explained it, you have offered a solution that does not work in all situations, so don't use %L.

Can't we just have %L point to the default log path as declared in the global preferences menu?

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #25 on Sat 14 Apr 2007 10:21 PM (UTC)
Message
Quote:

most people when they read that it provides the, "log path", are going to look at the directory structure for Mushclient, see that there is a path like "c:\program files\mushclient\logs" and *assume* that this means that the default location for that path is going to be the application path + "\logs\"


You haven't replied to my question about whether it should be the application path or the startup directory path.

Technically, you shouldn't be writing to anything in the application path because that is shared between multiple users, and should even be set to read-only.

The startup directory should be a writeable directory that is unique to each user.

I might also point out that if I am using any program at all (like Word for example) and I ask it to open a file in a relative path, expect it to be a relative path to where I currently am, not to where the application happens to be on disk.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #26 on Sun 15 Apr 2007 07:41 PM (UTC)
Message
Hmm. Ok, Nick, you have a point in that case, assuming you want to get that complicated. Under XP, Vista, etc. it would be the current user, under older ones, it would be the application path, since there is no "user" path. But that brings up another issue. Mainly, if you are going to put it in:

Win XP, etc. - Current User:/MUSHClient/
Win 98 < - /My Documents/

Then you need to either a) inform the user than the directory doesn't exist and ask if they want to create it *or* b) automatically create one. And if you really want to argue about that, then logically, on something like XP, the folder paths would have to be:

C:\Program Files\MUSHclient - main application and other support files.
C:\Documents and Settings\User_Name\MUSHclient\Worlds
C:\Documents and Settings\User_Name\MUSHclient\Plugins
C:\Documents and Settings\User_Name\MUSHclient\Logs

And so on. In any case, you have to make sure there is a directory to open/create something in at all. Frankly, for myself, I prefer to keep it where it is, even for XP, simply because if I change users I don't want to "lose" access to thing. But, if you really want to worry about that, then yes, any user data should be placed in the "users" data area, not in the program directory structure. That just opens a new can of worms though, especially if someone, like me, doesn't want it being put there and locked to a specific user account. In any case, the logical place for the data under older ones is "My Documents", but about 50% of the programs I know don't do that, and you still have the, "I am sorry, but the folder you are trying to put it in doesn't exist.", issue, not to mention that if you "do" put it in there you still need to make sure the name is unique, by doing what I show above and placing the files in "MUSHclient\Logs", not just "Logs".

It makes more logical sense in a way to do that (not that logic is high on the list of priorities for Windows software...), but it means adding checks for OS version, checks for user name on those that use them, checks for the existence of folders, code to create or request creation of them if they don't exist, and so on. And still installations only happen on those in the root system, you may also need to set up folders for "each" user that will use it, either at initial install or when each user runs it (the later being probably easier).

And no, the "document" directory should be unique and writable for each user. That isn't the same thing as the "startup" directory at all. Things like Word tend to remember the last place you opened/wrote something. The nicer ones remember each independently, so if you are doing something like image manipulation the "open" path doesn't mess with the "save" path. But they most certainly don't use, "where I currently am, according to the OS.", usually. The ones that do are imho, a major pain in the ass to use, since 90% of the time you have to navigate to what ever you are actually trying to do, even if 100% of the time the files you open with it are in the same place.

In any case, right now MUSHclient isn't XP aware. It has no clue that user profiles exist, that its running in one or that there is a document folder for that user. Its program directory ***is*** its document path, so its "startup" location is its own directory path. That means that at the moment its actually using "something else's" startup path/document path (depending on what the last application run was doing), when it tries to open a file, instead of its own. And that is where the problems are coming from. Word would break the same way if it used the path for some other program every time it did something, instead of remembering the last path you used *in it*, or using the path to the document you opened with it. That is the only case where the document path should change, if the document you open is some place other than where the program would normally look. And even then, unless you want to make plugins, logs, etc. sub paths to the worlds, those have their "own" document paths that are independent of the world files, in the current design.

Or to put it another way, you don't expect something like OpenOffice to look for word documents, spreadsheets and databases all in the "same" place you last opened a word document. You expect it to know that you last saved the word document in foo\bar, the last spreadsheet in foo\rab and the last database in foo\dbs, and not confuse those. But if you open something in foo\junk, you expect it to remember that "that" file is in foo\junk, and to not change directories on you, unless you do "Save As", and thus force it to forget the "foo\bar" location it normally starts in when opening files. Right now MUSHclient is doing the equivalent of starting in foo\bar, having something else start two seconds later in foo\me, and then trying to open its logs in foo\me instead of where *it* started. To use Word as an example, Word would **never** do this, nor would 90% of the other programs that exist.
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #27 on Sun 15 Apr 2007 09:28 PM (UTC)
Message
Quote:
Or to put it another way, you don't expect something like OpenOffice to look for word documents, spreadsheets and databases all in the "same" place you last opened a word document. You expect it to know that you last saved the word document in foo\bar, the last spreadsheet in foo\rab and the last database in foo\dbs, and not confuse those. But if you open something in foo\junk, you expect it to remember that "that" file is in foo\junk, and to not change directories on you, unless you do "Save As", and thus force it to forget the "foo\bar" location it normally starts in when opening files. Right now MUSHclient is doing the equivalent of starting in foo\bar, having something else start two seconds later in foo\me, and then trying to open its logs in foo\me instead of where *it* started. To use Word as an example, Word would **never** do this, nor would 90% of the other programs that exist.

I actually get quite annoyed at Firefox because of this method of storing files. If I save a picture, then go to save a text file, then a .zip, and I want it all in the same directory, I have to select that directory each time. There is no guarantee that just because I saved a picture to one directory means that I want to save every picture there.

The program nedit takes an interesting approach that sort of splits between the two ideas. The current file directory is whatever the directory is of the document you currently have on top. If you go to another tab with a file based in a different directory, then you will get that file's directory as the base. If you don't have a file that has been saved, it defaults to the directory in which you started the program.


Another odd issue to go along with the default directories in the method that you suggested for going into the documents folder automatically, is that you may not always run the program from the same spot all the time. I carry a copy of MUSHclient on a usb drive when I travel. There is no way to be sure that I have a user account on the computer that I'm using (could be logged in as a guest). Also, there certainly isn't a way to make sure that the usb drive will ever even have the same drive letter. This is the situation where I have a script grab all the information I need to make the relative file paths work instead of trying to use internal links.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #28 on Sun 15 Apr 2007 09:58 PM (UTC)
Message
Quote:

That just opens a new can of worms though ...

...

In any case, right now MUSHclient isn't XP aware. It has no clue that user profiles exist, that its running in one or that there is a document folder for that user.


I agree about the can of worms. :)

Well it was written before XP existed, however I should point out that the "global preferences" are stored in the Registry, under HKEY_CURRENT_USER. That means that if you change users (ie. profiles) then you would get a different set of global preferences. Now, the global preferences contain your paths like DefaultWorldFileDirectory.

Thus, changing users should let you get a different default world file directory. eg.


HKEY_CURRENT_USER\Software\Gammon Software Solutions\MUSHclient\Global prefs\DefaultWorldFileDirectory

In my case that contains:

C:\Program Files\MUSHclient\worlds\


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #29 on Sun 15 Apr 2007 10:00 PM (UTC)
Message
Probably the real bug here is in the installer, in that it should not even put relative paths in the global preferences in the first place.

Also it should make the default world directory somewhere in your Documents folder and not your Program Files folder.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[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.


95,262 views.

This is page 2, subject is 3 pages long:  [Previous page]  1  2 3  [Next page]

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]