Scenario:
authotkey is installed - autohotkey.exe is associated with .ahk files.
In some other directory is another autohotkey.exe located - but a different version.
Now i press Ctrl-Enter over this other version to move it down in the command line and start it. Total commander runs now the wrong file -> from the directory where the association points to.
If i make " around the autohotkey.exe, it works and the current directory is used.
Problem with launching programs from current directory
Moderators: Hacker, petermad, Stefan2, white
That would mean i can never start any other file with the same name from another location? Are you sure?If you have associated some EXE with file type and press Enter, associated program should be started anyway (if it is configured using full path).
In pure command line this works as it should -> starts the exe from current dir.
And file type is not even used here - there is no .ahk file involved...
When application is executing file, it is searched in current directory at first, then in directories specified in PATH environment variable. If file with given name is found in current directory, it is started even if files with same name exist in other directories.
You may use full path to start any with same name from any location. And, you may use Ctrl+Shift+Enter to paste full path to TC command line.
You may use full path to start any with same name from any location. And, you may use Ctrl+Shift+Enter to paste full path to TC command line.
Related Topic:
Starting firefox in C:\Program Files instead of...
And i agree: "this is not expected" from command line.
Regards
Holger
Starting firefox in C:\Program Files instead of...
And i agree: "this is not expected" from command line.
Regards
Holger
thanks Holger for the related link!
Seems to be the same problem. I'm a little confused how old the thread is and the bug is still there.
And it is clearly a bug - TC is even writing the path on the left of the command line and then it starts from somewhere else? Come on...
If there are really people, who want it like that (i guess 99% dont even know about), then just make it configurable...
I hope it will be fixed soon - i dont want to regret the money i payed for TC (and customs!)
Seems to be the same problem. I'm a little confused how old the thread is and the bug is still there.
And it is clearly a bug - TC is even writing the path on the left of the command line and then it starts from somewhere else? Come on...
If there are really people, who want it like that (i guess 99% dont even know about), then just make it configurable...
I hope it will be fixed soon - i dont want to regret the money i payed for TC (and customs!)
Hello, reflex.
If it is the same problem as discussed in the old thread, then the bottom of the problem is not a Total Commander bug, but a design decision:
Windows apparently can override search path and fully qualified executable file names with the help of an entry inside the "App Paths" registry key.
The quesion which has never been discussed and decided upon is whether Total Commander is supposed to respect such an "App Paths" entry or whether it should ignore it.
The workaround is pretty simple: remove the offending "App Paths" entry manually thus restoring the expected search behaviour.
Therefore, calling T.C. unusable because it respects the Windows "App Paths" priority is exaggerated. I doubt that you will get back your registration fee because T.C. respects a Windows priority rule although most of us will consider this rule absurd.
Kind regards,
Karl
If it is the same problem as discussed in the old thread, then the bottom of the problem is not a Total Commander bug, but a design decision:
Windows apparently can override search path and fully qualified executable file names with the help of an entry inside the "App Paths" registry key.
The quesion which has never been discussed and decided upon is whether Total Commander is supposed to respect such an "App Paths" entry or whether it should ignore it.
The workaround is pretty simple: remove the offending "App Paths" entry manually thus restoring the expected search behaviour.
Therefore, calling T.C. unusable because it respects the Windows "App Paths" priority is exaggerated. I doubt that you will get back your registration fee because T.C. respects a Windows priority rule although most of us will consider this rule absurd.
Kind regards,
Karl
karlchen, if file to be launched presents in current folder, it must be launched regardless of any PATH or "App Paths". Only if file is not found in current directory TC may look for other paths. If I see file in current directory, type its name - and TC starts another file - it is 100% bug or very bad unlogical behaviour.
@karlchen:
You must be kidding!
Are you a responsible developer? Cause then i would demand my registration fee back! What a kind of discussion and solutions!
Do you really think, i mess with the registry, only cause of a buggy program? Do you do that? Do you have admin rights everywhere? Never use TC with USB stick on different machines?
Windows overrides search path? Hä?
If i start a console, enter a filename and this file is present in the current directoy, it will be started. <-Period
And nothing more should happen in TC. What part of that do you dont understand?
I saw already in the old thread some kind of ignorance and 2 years later its the same story?
Why is the developer unable to fix this? This must be 3 lines of code! With a switch maybe 10!
You must be kidding!
Are you a responsible developer? Cause then i would demand my registration fee back! What a kind of discussion and solutions!
Do you really think, i mess with the registry, only cause of a buggy program? Do you do that? Do you have admin rights everywhere? Never use TC with USB stick on different machines?
Windows overrides search path? Hä?
If i start a console, enter a filename and this file is present in the current directoy, it will be started. <-Period
And nothing more should happen in TC. What part of that do you dont understand?
I saw already in the old thread some kind of ignorance and 2 years later its the same story?
Why is the developer unable to fix this? This must be 3 lines of code! With a switch maybe 10!
Hi, guys.
Cool down. As I stated I agree with you that the "App Paths" feature can have unexpected side effects. Telling from the behaviour of cmd.exe, even Microsoft does not seem to think that taking "App Paths" into consideration is mandatory.
Only Christian Ghisler can tell why he does not make sure to ignore "App Paths" entries. And he is not only the responsible developer, but the only developer.
I just played devil's advocat, because we might as well bash Microsoft for introducing such a stupid feature like "App Paths". But I guess doing so is less likely to have the desired effect than complaining about T.C.
Cheers,
Karl
Cool down. As I stated I agree with you that the "App Paths" feature can have unexpected side effects. Telling from the behaviour of cmd.exe, even Microsoft does not seem to think that taking "App Paths" into consideration is mandatory.
Only Christian Ghisler can tell why he does not make sure to ignore "App Paths" entries. And he is not only the responsible developer, but the only developer.
I just played devil's advocat, because we might as well bash Microsoft for introducing such a stupid feature like "App Paths". But I guess doing so is less likely to have the desired effect than complaining about T.C.
Cheers,
Karl
@karlchen: Can you provide some links?
I could not find any relevant info from Microsoft about "app paths" and especially about the described behavior - the only info i could find is, that the app path is appended to the path environment variable, when using api call ShellExecute(), but the path will be evaluated after the current directory...(except in TC)
Devil's advocat? Well, for me your solutions and arguments sounded as you would not take this problem serious - but if you are not involved with TC it is ok.
I could not find any relevant info from Microsoft about "app paths" and especially about the described behavior - the only info i could find is, that the app path is appended to the path environment variable, when using api call ShellExecute(), but the path will be evaluated after the current directory...(except in TC)
Devil's advocat? Well, for me your solutions and arguments sounded as you would not take this problem serious - but if you are not involved with TC it is ok.