Gammon Forum : MUSHclient : Bug reports : Path bug...

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

Bug reports

Path bug...

Path bug...

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

Pages: 1 2 3

Posted by

Shadowfyr USA (1,786 posts)

Date

Sun 08 Apr 2007 09:22 PM (UTC)

Message

I have my client set to open a new log every time I connect to the world I play, I just noticed today that the last "successful" creation of a log was on:

12-25-2006(04-21 PM)

Ever since then (and what ever version came out after that date) it has apparently been failing to create the log file, since the %L path is being derived off of the "current" directory, instead of off of the program directory. In other words, since I opened some other program and fiddled around after Mushclient was running, it apparently retrieved what the "system" thought was the current directory, looked for a folder called "logs" there, didn't find it, beeped (or just failed to open one silently, then went on as though I never tried to open one. I have now manually set the correct directory until we figure out what the heck is going on here. :(

Basic rule seems to always be, "Never trust the OS to give you the "right" location for where you need to be *ever*!" lol

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #1 on Sun 08 Apr 2007 09:42 PM (UTC)

Message

I suggest you go into global preferences and change the log files directory to be a fixed path, not a relative one.

The whole thing with the "current directory" is driving me crazy, I can't think of a good way around it.

The problem is basically caused because when you open a file browser dialog box, the flag is set to allow the directory to change.

In other words, if you use the Notepad to edit some scripts, then once you browse to your scripts directory, that becomes your current directory, so trying to open a second file remembers where you were. It would be quite annoying to have to re-browse every time.

However the big catch is, now the current directory has changed, if you are logging to (say) ".\\mylogs", then it now looks for that as a subdirectory of your scripts, and not your world file.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #2 on Sun 08 Apr 2007 10:05 PM (UTC)

Message

Ah. Ok. I missed the setting for that.

Posted by

Onoitsu2 USA (248 posts)

Date

Reply #3 on Mon 09 Apr 2007 09:22 AM (UTC)

Message

ok I can think of one solution to the directory problem, and will lay out the idea as follows...

Upon RUNNING of MUSHclient, have it retrieve its location and store this in a variable (internal C++) that other functions will use to Prepend relative paths, i.e. those starting with a period, or 2 periods, THEN pass it to the proper function that will use the path attained.

When I make a program in Autoit, and I need to use relative paths to the program itself I do the same task, but then again it is automatically done and placed into a variable @ScriptDir, and the script/executable FULL path is stored in @ScriptFullPath

I don't know HOW to impliment such a fix, BUT that would correct nearly ANY issue with relative pathing, the only issue might be using Wine, as I don't know how it handles relative pathing.

Laterzzz,
Onoitsu2

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #4 on Mon 09 Apr 2007 05:38 PM (UTC)

Message

With Wine, when I press shift-ctl-J, a file selector pops up in the right place. This is after I changed directories a few times to load plugins in weird spots, and used Notepad in Wine to change directories. It seems that Wine is storing the working directory as the "current directory" or just does better at keeping track of what program is looking where.

I hesitate to report this as a bug at winehq, but I guess for 100% compatability, you have to include the stupid.

Also, with logging, MC just dumps whatever I have in the output buffer into the file. I don't log much (don't think I've used the logging more than twice in the 10+ years I've used MC), so I don't know if I'm doing something weird or Wine is. How do I get the client to continually put new lines into the log file?

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

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #5 on Mon 09 Apr 2007 05:58 PM (UTC)

Message

Nevermind... it's working. I just had to wait a bit for some of the text to get added. Just hitting enter a few times to get the prompt didn't put anything new in, even though the prompt is logged. Seems to be working well now that I'm actually out doing things.

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

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #6 on Tue 10 Apr 2007 07:40 AM (UTC)

Message

Well. The problem is, if you get the current directory when it starts, are you getting the "current" directory or the "start in" path stored in the short cut? Now, running the application directly means you always get the right path, since its "start" location is always the same as the file. But under Windows, you can define a different location for it to start in, which is then returned by some functions for getting the path... Its a major pain in the ass..

It also looks like another one of those, "Duh! Its so easy why can't you figure out out?", problems, like one we have been talking about now and then...

Posted by

David Haley USA (3,881 posts)

Date

Reply #7 on Tue 10 Apr 2007 08:08 AM (UTC)

Message

Wait, why is it bad that you can override the initial current directory of a program? On the contrary that is an extremely useful thing to be able to do...

To answer your question, if you get the current directory when it starts, then assuming the current directory has not been changed, then yes, you will get the initial directory, aka initial working directory.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #8 on Tue 10 Apr 2007 12:27 PM (UTC)

Message

Quote:

Upon RUNNING of MUSHclient, have it retrieve its location and store this in a variable (internal C++) that other functions will use to Prepend relative paths ...

Well this isn't as easy as it looks. For one thing, when running a script you don't know if the script will open files. Maybe the script will deliberately change the current directory and it will be broken if you change it back.

Things can get heavily nested. For example a script does a LoadPlugin, the plugin loads an include file, the include file does a "require" of a Lua file, the "required" file opens a disk file.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #9 on Tue 10 Apr 2007 07:31 PM (UTC)

Message

Not sure if that is relevant Nick. The point here is to make sure the *base* directory is the same from the moment it loads and thus that things like the main program directory remain the same all the time, not to force the application to always stay in the same directory. In theory, the real problem with logs is either a) %L tries to use the "current" directory as in ".\logs", unless you specify one or b) we need a %M that will always be the location where Mushclient started, so that %M%L will be "C:\Program Files\MUSHclient\" + "logs\" (presuming it starts in the default install location). specific folders, like log files, etc. shouldn't "ever" use the current directory, but instead should always use one either a) derived from the initial start location or b) one *specifically* given by the person either manually opening one in the script or from the user specified default location, in cases where the person wants to put them some place else. Where the "current" directory is relative to any of this is completely irrelevant and shouldn't have any effect at all, "unless" someone specifies when manually scripting the location to open a log, etc., that they want it created/opened locally using "." or "..", then its their problem if they or something else changed the current directory before doing that (and imho its bad practice to do that anyway, precisely because its not 100% certain that it will remain the same).

Most things, like a DOS window, for example, or other applications, get the current directory, store that, then keep track of *only* those changes *it* makes to that path, so that its own "current" location remains independent of what the system thinks it is. Its just basic common sense. The only time the "current" path is used, from the OS, is during initial startup and in cases where you are opening a file and the assumption is that the last open folder is where you want to load it from. This imho is both good and bad too. Some programs default to their own location for that, and its a pain to navigate to some place else to find the file you want. Others store the last place you had opened in the system registry, so it can start their. Still others take the current working location, which can be either where they started, or where you last opened something after the program itself is running. Imho, the first and third are useless, with both in a tie as to just how useless they are, depending on the situation. You get the **exact** same problem if you just happen to have something else, like a text editor, open, (it) changes the OS working directory and your script then tries to open something that isn't where its supposed to be anymore either. Its generally much better if the application/script keeps its own track of where things are, including it own "last opened" location and ignores what the bloody OS thinks is going on. Relying on the OS to know what is happening is absurd, dangerous and nearly always useless.

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #10 on Tue 10 Apr 2007 09:32 PM (UTC)

Message

Quote:

Most things, like a DOS window, for example, or other applications, get the current directory, store that, then keep track of *only* those changes *it* makes to that path, so that its own "current" location remains independent of what the system thinks it is.

I'm not sure what you mean by that. I don't think they do any such thing.

Look, the current path is the path that is used when a file is opened without an absolute path. So for example, if the current path is c:/foo/bar and a program opens "abc.txt" then it is really c:/foo/bar/abc.txt.

Programs don't normally store the current directory. Each process maintains its own notion of the current directory. So, if you start two DOS windows, and in one change (cd) to /foo, and in the other change to /bar, and then attempt to open a file, it will open in the new directory.

It would be ridiculous and unwieldy if every time the program decided to change directories (programatically, 'chdir ("/foo")' ) it also had to keep a "working copy" of the current directory.

Quote:

Relying on the OS to know what is happening is absurd, dangerous and nearly always useless.

It isn't clear to me how such a scheme would work in a scripting framework. You are suggesting the application should "know better" than the operating system what the current directory is. So, when you call a script (eg. on a trigger), the script can do anything, including open files. How can I second-guess what the script code might do and prepend the current path to any open calls it may or may not make?

Conceivably a script might call a DLL, and the DLL might open a file in the current path.

Quote:

In theory, the real problem with logs is either a) %L tries to use the "current" directory as in ".\logs", unless you specify one or b) we need a %M that will always be the location where Mushclient started, so that %M%L will be "C:\Program Files\MUSHclient\" + "logs\" (presuming it starts in the default install location).

Well I think you are right, the problem is using relative paths in the first place. But if you did what you suggest, and then later browsed for a different log file path, the path could end up being:



C:\Program Files\MUSHclient\C:\Program Files\MUSHclient\logs

In other words, adding in the application directory in front of a *non-relative* path would then break things.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #11 on Tue 10 Apr 2007 09:47 PM (UTC)

Message

I should point out that GetInfo (66) returns the application directory.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #12 on Tue 10 Apr 2007 10:07 PM (UTC)

Message

Quote:

... we need a %M that will always be the location where Mushclient started ...

%M is already used for minutes, however I get the general idea. In version 4.03 will be %E which will be the initial (startup) directory.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #13 on Wed 11 Apr 2007 07:11 PM (UTC)

Amended on Wed 11 Apr 2007 07:15 PM (UTC) by Shadowfyr

Message

Quote:
It would be ridiculous and unwieldy if every time the program decided to change directories (programatically, 'chdir ("/foo")' ) it also had to keep a "working copy" of the current directory.

Wait, what!!! No, what I mean is that it you have two DOS windows open and you do "cd foo" in one of them, the other one doesn't go back and go, "Gosh! The current directory changed, better look in foo now!" It remembers where "it" is. This is obviously a bit harder to manage with scripts, but we are not talking about scripts here, we are talking about Mushclient itself remembering where the heck **it** is supposed to be looking when you use its own functions. This isn't a fracking DOS window and we are not sending the OS a series of commands like:

cd c:\MY Documents\
open log .\logs

It makes no sense for it to be using a relative path based on where some completely different program last opened something. If anything else did this you would have a major mess. Imagine, for example, you are working on a paper for some projects and you save it, only 5 seconds before you do your virus scanner opens something in "its" directory, and so now your copy of Word decides to save all its files in "that" location, instead of in the folder "it" considers to be the default for documents. Oops! No, ***not*** keeping a predetermined location and making the people who want to use some other location "specifically" say so is what is *unwieldy*.

Quote:
Well I think you are right, the problem is using relative paths in the first place. But if you did what you suggest, and then later browsed for a different log file path, the path could end up being:

C:\Program Files\MUSHclient\C:\Program Files\MUSHclient\logs

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

Point being. If someone gives a relative path, it should be relative to the program's path, not what ever arbitrary path happens to currently be active. If someone gives a non-relative path, then 99.9% of all existing applications go, "Ah, OK. You want to change directories or even volumes entirely, no problem, I will just ignore the path I have and use yours, **for this operation**. Unless there is a specific command for "changepath" or the like, this has "no" effect on where everything else goes. If you don't do it that way, then its *impossible* to know where the frack the new file will end up, since *anything* running on the same machine might change the main part of the path, invalidating the original location. Think about it. Lets say I am writing a log "only" occationally to, I don't know, keep track of in game lotto winnings, but nothing else. I am closing them opening a log, changing the name to have the exact time in it, but not keeping it open. The location I "want" it to be in is "c:\program files\muschlient\logs", so I open a file using ".\logs\blah.txt" Now, I open one, it works, the file is written, I close it. WinAMP or something opens a new file in "c:\my music\anime", this changes the "current" directory, so the next attempt to open a relative path is actually "c:\my music\anime\logs\blah.txt". Oops! It doesn't even open. The next thing is some download manager, which opens and starts downloading a file, it just ran from "c:\program files\my downloader\". This time it works, because it "does" have a "logs" directory, only they are not where the are "supposed" to be, since I have been assuming that the path is going to be relative to the application I am using, not what ever semi-random location the OS may now be pointing to.

It every application handled relative paths the way yours does Nick, with all due respect, the machine would be unusable and no one would have a clue where anything was saved. You are not second guessing "everything" the script is going to do, just the ones related to "your" client, where the logical expectation is that they are relative "to" that client, not some arbitrary location that can't be controlled. If some fool wants to use something like the system io functions in Lua to futz around and "they" put there own stuff in a relative path that isn't derived from anything, that is *their* problem. lol

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date

Reply #14 on Wed 11 Apr 2007 09:11 PM (UTC)

Amended on Wed 11 Apr 2007 11:43 PM (UTC) by Nick Gammon

Message

Quote:

If you don't do it that way, then its *impossible* to know where the frack the new file will end up, since *anything* running on the same machine might change the main part of the path, invalidating the original location.

I think you are confusing multiple processes here. Naturally, changing the current directory in (say) Word, would not affect MUSHclient, and vice-versa.

There is no "current directory" for the PC you are sitting at - for "you" the user. It is current for an application - a process.

The whole point of current directories is, that if the application chooses to change it, then from that point on, relative paths are relative to the new location.

Quote:

... so that %M%L will be "C:\Program Files\MUSHclient\" + "logs\" ...

C:\Program Files\MUSHclient\C:\Program Files\MUSHclient\logs

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:". I

What script? You just said you wanted to be able to use %M%L in your log file pathname. My point was if %M contained the application path, and %L was the log file path - an absolute path - then you would get the file name I gave as an example.

Your suggestions aren't consistent. You asked for %M to be the application path. You didn't say anything about "and if it happens to be next to a %L then you have to check if they are both absolute paths, and delete the absolute part of one of them". In any case, which one would you ignore? If %M was on D: and %L was on E: which one takes preference? I'm not doing anything absurdly silly here, you are suggesting that you be allowed to concatenate two possibly conflicting paths, and I am pointing out the pitfalls.

You are firing off suggestions, and I am trying to make you think about the total ramifications of them.

Quote:

If someone gives a relative path, it should be relative to the program's path, not what ever arbitrary path happens to currently be active.

Even this suggestion is fraught with peril. You say "the program's path", not the "initial directory". Is that really what you mean?

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.

If I did what you suggest and make the open relative to the "program's path", then all logs will be in 'C:\Program Files\MUSHclient\logs', which is where neither of you want them.

You really need to think carefully about what you are suggesting. I have added a new feature in version 4.03, to let you specify the startup directory in log file name:

http://www.gammon.com.au/scripts/showrelnote.php?version=4.03&productid=0

Thus, the logical thing to do, if you didn't want to specify an absoluate path for the logs in the global configuration, would be to log to something like:



%E\logs

Quote:

... but we are not talking about scripts here, we are talking about Mushclient itself remembering where the heck **it** is supposed to be looking when you use its own functions

I still maintain that for MUSHclient to "remember where it is supposed to be", is like asking it to "remember the time" because, as you put it "Relying on the OS to know what is happening is absurd, dangerous and nearly always useless.". You have to rely on the operating system a little bit.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

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.

90,201 views.

This is page 1, subject is 3 pages long: 1 2 3

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

Go to topic: Search the forum

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.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )