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

 

[jeff elkins]

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.dirname(sys.argv[0]))

Works perfectly, thanks much!

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.dirname(sys.argv[0]))

 

[Grant Edwards]

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

 

[Grant Edwards]

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.dirname(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.

 

[jeff elkins]

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.dirname(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

 

[jeff elkins]

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.dirname(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

 

[Robert Kern]

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.dirname(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
(e-mail address removed)

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

 

[jeff elkins]

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.dirname(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

 

[Mike Meyer]

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.dirname(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

 

[Grant Edwards]

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

argv[0] contains whatever is put there by the program that
exec'ed you, and can therefore contain just about anything (or
nothing). It may not contain a full path, and your program's
install directory may not be in your $PATH (it be executed by a
shortcut or symlink).

If you're controlling how the program is installed and started,
then you're probably safe.

 

[Dennis Lee Bieber]

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?

Even worse -- I've got a few applications that won't even run
from a "user account" because XP "protects" the normal "program files"
install directory, and the application tries to open/update the
configuration files.

--

 

[Bernhard Herzog]

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

argv[0] contains whatever is put there by the program that
exec'ed you, and can therefore contain just about anything (or
nothing). It may not contain a full path, and your program's
install directory may not be in your $PATH (it be executed by a
shortcut or symlink).

That's true for the C-level, i.e. main's argv. If you're only concerned
about CPython and the program is a script living in a file, then
sys.argv[0] is the filename the python interpreter itself used to read
the script. Hence it's a valid filename that refers to the script. It
may be a relative filename, of course, in which case it won't be correct
anymore if the program changes its working directory.

Bernhard