Finding startup files

[jeff elkins]

I'm creating an app that relies on a configuration file at launch. The file
will always exist in the app's installation directory, but I have no control
over where that might be.

Is there an OS-independent way that I can instruct the app to look in it's
home directory for startup files? Right now, I'm hard coding the path, which
won't work.

Thanks,

Jeff

[hemagician]

The following script demonstrates a method that should work for you. I
believe it is entirely cross-platform.

#! /usr/bin/python

import sys
import os

print os.path.abspath (os.path.dirnam e(sys.argv[0]))

[Grant Edwards]

On 2005-05-11, jeff elkins <je********@ear thlink.net> wrote:

I'm creating an app that relies on a configuration file at
launch. The file will always exist in the app's installation
directory,
That's the first decision you need to examine. If you want
work on Unix platforms, that's not where configuration files go.
If you're talking about Windows, then all bets are off and you
can ignore the rest of this post.
but I have no control over where that might be.
Exactly.
Is there an OS-independent way that I can instruct the app to
look in it's home directory for startup files?
No. That's not even the right place to look under Unix. If
you want to do things the "right" way under Unix, you look in
places like

/etc/<appname>
/etc/<appname>/whatever
/usr/local/etc/<appname>
/usr/local/etc/<appname>/whatever

One of the above would be used for system-wide configuration
stuff.

$HOME/.<appname>rc
$HOME/.<appname>/whatever

One of the above would be used for user-specific configuration
Right now, I'm hard coding the path, which won't work.

--
Grant Edwards grante Yow! I am covered with
at pure vegetable oil and I am
visi.com writing a best seller!

[jeff elkins]

On Wednesday 11 May 2005 04:32 pm, he********@gmai l.com wrote:

The following script demonstrates a method that should work for you. I
believe it is entirely cross-platform.

#! /usr/bin/python

import sys
import os

print os.path.abspath (os.path.dirnam e(sys.argv[0]))

Works perfectly, thanks much!

Jeff

[Grant Edwards]

On 2005-05-11, he********@gmai l.com <he********@gma il.com> wrote:

The following script demonstrates a method that should work for you. I
believe it is entirely cross-platform.

#! /usr/bin/python

import sys
import os

print os.path.abspath (os.path.dirnam e(sys.argv[0]))

That will probably work most of the time, but...

1) you're not gauranteed that argv[0] contains the application
path/filename.

2) the directory containing the executable is not where
configuration files are supposed to be stored under
Unix/Linux.

--
Grant Edwards grante Yow! hubub, hubub, HUBUB,
at hubub, hubub, hubub, HUBUB,
visi.com hubub, hubub, hubub.

[jeff elkins]

On Wednesday 11 May 2005 04:44 pm, Grant Edwards wrote:

On 2005-05-11, he********@gmai l.com <he********@gma il.com> wrote:

The following script demonstrates a method that should work for you. I
believe it is entirely cross-platform.

#! /usr/bin/python

import sys
import os

print os.path.abspath (os.path.dirnam e(sys.argv[0]))

That will probably work most of the time, but...

1) you're not gauranteed that argv[0] contains the application
path/filename.

2) the directory containing the executable is not where
configuration files are supposed to be stored under
Unix/Linux.

Thanks Grant,

I live and develop in Linux, but unfortunately, 99.99% of the users of this
particular application (analysis of medical laboratory data) will be working
with Windows.

I'm totally new to Python (obvious,yes?) so how might argv[0] fail?

Jeff

[Robert Kern]

jeff elkins wrote:

On Wednesday 11 May 2005 04:44 pm, Grant Edwards wrote:

On 2005-05-11, he********@gmai l.com <he********@gma il.com> wrote:

The following script demonstrates a method that should work for you. I
believe it is entirely cross-platform.

#! /usr/bin/python

import sys
import os

print os.path.abspath (os.path.dirnam e(sys.argv[0]))

That will probably work most of the time, but...

1) you're not gauranteed that argv[0] contains the application
path/filename.

2) the directory containing the executable is not where
configuration files are supposed to be stored under
Unix/Linux.

Thanks Grant,

I live and develop in Linux, but unfortunately, 99.99% of the users of this
particular application (analysis of medical laboratory data) will be working
with Windows.

I'm totally new to Python (obvious,yes?) so how might argv[0] fail?

If I make a symbolic link to the executable script and run it using that
link, sys.argv[0] will give the filename of that link, not the real file
it points to.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[jeff elkins]

On Wednesday 11 May 2005 10:18 pm, Robert Kern wrote:

jeff elkins wrote:

On Wednesday 11 May 2005 04:44 pm, Grant Edwards wrote:

On 2005-05-11, he********@gmai l.com <he********@gma il.com> wrote:
The following script demonstrates a method that should work for you. I
believe it is entirely cross-platform.

#! /usr/bin/python

import sys
import os

print os.path.abspath (os.path.dirnam e(sys.argv[0]))

That will probably work most of the time, but...

1) you're not gauranteed that argv[0] contains the application
path/filename.

2) the directory containing the executable is not where
configuration files are supposed to be stored under
Unix/Linux.

Thanks Grant,

I live and develop in Linux, but unfortunately, 99.99% of the users of
this particular application (analysis of medical laboratory data) will be
working with Windows.

I'm totally new to Python (obvious,yes?) so how might argv[0] fail?

If I make a symbolic link to the executable script and run it using that
link, sys.argv[0] will give the filename of that link, not the real file
it points to.

Thanks. I just tested that and it does indeed fail.

Jeff

[Mike Meyer]

jeff elkins <je********@ear thlink.net> writes:

On Wednesday 11 May 2005 04:44 pm, Grant Edwards wrote:

On 2005-05-11, he********@gmai l.com <he********@gma il.com> wrote:

> The following script demonstrates a method that should work for you. I
> believe it is entirely cross-platform.
>
> #! /usr/bin/python
>
> import sys
> import os
>
> print os.path.abspath (os.path.dirnam e(sys.argv[0]))

That will probably work most of the time, but...

1) you're not gauranteed that argv[0] contains the application
path/filename.

2) the directory containing the executable is not where
configuration files are supposed to be stored under
Unix/Linux.

Thanks Grant,

I live and develop in Linux, but unfortunately, 99.99% of the users of this
particular application (analysis of medical laboratory data) will be working
with Windows.

Yes, but Windows these days supports multiple users. Are you sure that
you want to restrict your users to one configuration file per
installed version of the program?

I'm not sure Windows has a good solution to this problem. My
experiences with trying to share applications between users on Windows
haven't been very pleasant.

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[jeff elkins]

On Thursday 12 May 2005 05:24 am, Mike Meyer wrote:

jeff elkins <je********@ear thlink.net> writes:

On Wednesday 11 May 2005 04:44 pm, Grant Edwards wrote:

On 2005-05-11, he********@gmai l.com <he********@gma il.com> wrote:
> The following script demonstrates a method that should work for you. I
> believe it is entirely cross-platform.
>
> #! /usr/bin/python
>
> import sys
> import os
>
> print os.path.abspath (os.path.dirnam e(sys.argv[0]))

That will probably work most of the time, but...

1) you're not gauranteed that argv[0] contains the application
path/filename.

2) the directory containing the executable is not where
configuration files are supposed to be stored under
Unix/Linux.

Thanks Grant,

I live and develop in Linux, but unfortunately, 99.99% of the users of
this particular application (analysis of medical laboratory data) will be
working with Windows.

Yes, but Windows these days supports multiple users. Are you sure that
you want to restrict your users to one configuration file per
installed version of the program?

I'm not sure Windows has a good solution to this problem. My
experiences with trying to share applications between users on Windows
haven't been very pleasant.

<mike

With this particular app, a single config file per install is required. It
sets up parameters that may vary from laboratory to laboratory but never do
within a single lab.

However, it might be a good idea to check the environment and if running under
*nix store configuration (and data files, which I didn't mention) in a sane
manner. That would solve the symlink issue anyway...

Thanks for the feedback folks,

Jeff