GetCurrentDirectory() returned wrong value

[ward]

This bug appears in PB 5.4~5.5, both x86/x64 version.

Here is a very simple test code:

Code: Select all

MessageRequester("", GetCurrentDirectory())

Ok, compile it by "pbcompiler test.pb", copy the exe file to another path and then run it.
The output should be the new path, however, it shows the path of source code.
If you compile it by "pbcompiler test.pb /commented", the output is correct.

Here is the problem line in the PureBasic.asm.

Code: Select all

MOV rcx,_PB_SourceCodePath
extrn SetCurrentDirectoryA
CALL SetCurrentDirectoryA

It stores the source code path, set it as current directory at the beginning of program (but why?)
These lines won't exist when add "/commented" parameter.

[ts-soft]

You have different "CurrentDirectory" on Compiling for IDE/Debugging and for final Executable. You can/have to set the CurrentDirectory
for your final Executable by:

Code: Select all

CurrentDir$ = GetPathPart(ProgramFilename())

This Dir is also/only correct, for IDE/Debugging Compiling, if you use in Compiler Options: Create temporary executable in the source directory! or it shows to tempdirectory.

Sorry my bad english, no bug!

[ward]

I am sure it is a bug!!
Please make sure you did all step what I said.
(compile with/without /commented switch, and copy to different path before running)
You will know what's wrong.

PS. this bug only apper when you compile the source without any parameter.
pbcompiler.exe test.pb /exe 1.exe => OK
pbcompiler.exe test.pb /commented => OK
pbcompiler.exe test.pb => bug!!

Maybe the title misleading you. The bug is in the compiler, not in GetCurrentDirectory() function.
GetCurrentDirectory() is ok, but it returned wrong value if the compiler add some nonsense asm into the output.
I use this title because that's why I found this bug.

[Thunder93]

The problem is apparent to me.

When doing it manually and using pbcompiler "PATH\FILE.pb", the file is created in the compilers location. It is called from there, but the current directory information is influenced by the sourcecode pb location, when there are no additional parameters supplied.

when there are no additional parameters supplied, the current directory from pb sourcecode location, is hard coded. Changing executable locations and running, continues to bring up the current directory belonging to the sourcecode location.

... I don't think it's really that serious, because when you create executables via PB IDE, all is well. I think it's probably considered misuse of that utility anyways.

[Dude]

The output should be the new path

GetCurrentDirectory() is not for getting the exe's folder. Use ProgramFilename() for that.

[Thunder93]

Dude is right. To get the programs location, GetCurrentDirectory() command isn't the way to go. To easily influenced to show wrong locations.

For instance create a shortcut to this compiled executable. Update the shortcut 'Start in:' field with some other valid path. Now launch this shortcut, you'll not see your executable location.

A launcher utility calls your executable, you'll see the location of where the launcher executable is located, or whatever the current directory was set to ... SetCurrentDirectory() with this launcher utility.

[ward]

The output should be the new path

GetCurrentDirectory() is not for getting the exe's folder. Use ProgramFilename() for that.

Of course you are right, but what is your point?
GetCurrentDirectory() is for getting windows working directory.
To get the correct working directory is very important for some programs, for example, console tools.
I even don't care about exe's folder.

With this bug, you cannot get the correct working directory forever.
Because it is changed when the program starting.
Although this bug is easy to overcome (compile with some parameter, for example, /commented like I said)
But this is still a bug, right?
Who always use PureBasic with IDE will never find this bug.
But I use sublime text instead of the IDE, so I can find this bug, and then I report it.

I post this thread at "Bugs - Windows". Because I just want to report a bug and I never have any coding question.
In fact, I already point out the way to overcome the bug in first post.
And I also found out where is the incorrect assembly output from pbcompiler (let Fred or someone can fix it more easily).
I don't know who move this thread to "Coding Questions". It's very STRANGE and IMPOLITE.

[Thunder93]

Hi ward.

Fred was around earlier, he probably deemed it as misuse of that utility. This is a component that Fred created himself, I think he knows if it was by design or bug.

Now that we established that you do want the working directory..

pbcompiler sourcecode.pb

or

pbcompiler sourcecode.pb --debugger

..yields the same results.


If you looking to create an executable, you should be using;

pbcompiler sourcecode.pb /EXE "[Whatever_PATH]\[WhateverFilename].exe"

[ward]

I know the way to generate the exe file. But sometimes I don't need the output exe file.
pbcompiler.exe will execute a pb source code just like a script. And I think the script like behavior is useful to me.

The document also have the demonstration of the usage, I copy it to here:

Code: Select all

Examples: 
  CLI> pbcompiler sourcecode.pb
The compiler will compile the source code and execute it. 

See? This is a classic method to use pbcompiler noted in official document.
It's not a unofficial usage or some unsuggested way.

I agree Thunder93, maybe this is a design (for whatever reason).
However, it is not mentioned on any document.
For me, a design will lead to unexpected and undocumented behavior, is a bug.

If it is a design, I guess it's purpose is to assign working directory to source code path forcibly under IDE environment.
But in my opinion, overwriting the working directory in background is not a good way.
There are some more elegant ways to do it.

And I say again, I have no any "Coding Questions".
Who moved this thread? It's IMPOLITE for me.