Current path error

[Muhammad Bashir Al-Noimi]

Keryx has a serious problem in current and relative paths this problem appears clearly when you launch Keryx by using link or tree browsing as shown in the screenshot1.

[mac9416 (mac9416)]

Thanks for the bug report, this problem had never occurred to me. There must be a way to change the current working directory to the directory of the executable from within the program. I'll get to work on it.

[mac9416 (mac9416)]

The fix I have committed for this bug does not work when Keryx is compiled. We will make it clear in the tutorial that Keryx will not launch properly from a browser in tree view.

[Kevin Mac (knifethemac)]

Several months ago when I was doing some other WX stuff, I thought I saw a WX call that returned the path to executable.

I went looking for it two nights ago, but I wasn't able to find it. Perhaps another set of eyeballs could find it.

I also think that there should be an enviroment variable that contains the path to the executable, but I haven't had a chance to look for it yet.

[mac9416 (mac9416)]

Hey, Kevin,

I went looking around for a solution to this and found another one. Since it doesn't depend on __file__, I think it may work when compiled.

"""
import os
import sys
os.chdir(os.path.abspath(os.path.dirname(sys.argv[0])))
"""

That works when run as source. I will test it compiled soon.

[Kevin Mac (knifethemac)]

That's a great find. Yeah that should work for all the *nix OSes. I can't recall enough about Windows to be sure it works on all of those.

I did manage to find the WX call I was thinking about.
You're solution will be much cleaner, but I'll go ahead and repeat what I found in this post in the slight chance that your fix doesn't work in every case.

#####################################################################

Here's the WX call I was thinking about:

---------------------------------------------
wxStandardPaths::GetExecutablePath

wxString GetExecutablePath() const

Return the directory and the filename for the current executable.

Example return values:

    * Unix: /usr/local/bin/exename
    * Windows: C:\Programs\AppFolder\exename.exe
    * Mac: /Programs/exename
---------------------------------------------

I tried

wx.StandardPaths.Get().GetExecutablePath()

and it returns /usr/bin/python2.5 when running interpreted.

I didn't have time to try the compilation tutorial yet, so I'm
not certain what it returns in that case. But, It looks promising.
Unfortunately it would mean more conditional code for the interpreted
version vs. the compiled version.

Note that the extra ".Get()" is a static function so that an
instance of StandardPaths doesn't need to be created.

[Muhammad Bashir Al-Noimi (mbnoimi)]

On 20/02/2010 09:00 م, Kevin Mac wrote:
> That's a great find. Yeah that should work for all the *nix OSes. I
> can't recall enough about Windows to be sure it works on all of those.
>
Sorry for interruption ;-)

As I know Wx is a cross-platform toolkit so I think the solution will
work well on Win just like in Lin (I'm C++/Qt developer it's
cross-platform toolkit too) and because I'm using Linux and Windows too
I can easily test the new options within a short period.

This is all what I can help, so please forgive my trivial contributions
because I'm following your discussions and I can't contribute in the
code (I've no experience in Wx and Python)

--
Best Regards
Muhammad Bashir Al-Noimi
My Blog: http://mbnoimi.net

[mac9416 (mac9416)]

Kevin, good find. If sys.argv doesn't work well, that will make a good Plan B. :-)
Muhammad, thanks, let me know how your testing goes.

I'll probably be able to test both ways within a couple of days.

[Kevin Mac (knifethemac)]

I finally found time to try building the executable.

The sys.argv fix works on both Jaunty and Karmic for me.

Note that both of my systems have Python and WX installed. A better test would be to try it on a system without any of that stuff, but I'm too lazy to create a VM and install a bare-bones linux distro in it. :-(

And I don't do windows. :-)
So someone else will need to test that.

[mac9416 (mac9416)]

I just tried compiling with the sys.argv fix, but it seemed that it was confusing Pyinstaller. I'll keep tinkering with it and see if I can get it to work right. For now I'm going to try wx.StandardPaths.Get().GetExecutablePath().

As for testing on a bare-bones Linux install, I have a few live CDs that I intend to test it on.
I'll also test on a few XP machines.

[mac9416 (mac9416)]

Another fix!

It used to be that the locations of files were relative to the current working directory. The previous fixes I attempted depended on setting that current working directory. But wait a minute... That's a bit like storing the CWD in a variable, isn't it?

So now the current working directory is found using the tried-and-true sys.argv method and stored in a variable to be accessed by the rest of the code. Since the CWD is never changed, pyinstaller doesn't get confused.