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 |
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top