Linux application deployment
klappnase at web.de
Mon Sep 6 01:14:36 CEST 2004
Jarek Zgoda <jzgoda at gazeta.usun.pl> wrote in message news:<chfh9i$kda$1 at nemesis.news.tpi.pl>...
> Grant Edwards <grante at visi.com> pisze:
> >> import sys, os
> >> me = os.path.abspath(sys.argv)
> > That's only mostly reliable. Nothing in Linux/Unix actually requires that
> > argv be the program's path. It is the convention to pass that as
> > argv, but there may be corner cases where it doesn't work.
> Based on Python docs:
> The list of command line arguments passed to a Python script.
> argv is the script name (it is operating system dependent whether
> this is a full pathname or not). If the command was executed using
> the -c command line option to the interpreter, argv is set to the
> string '-c'. If no script name was passed to the Python interpreter,
> argv has zero length.
> In my opinion, this would be enough to get full path of currently
> running program, if run from script. Are there any caveats (except this
> "-c" option, which I don't count, as is not relevant in most cases)?
If you use a symbolic link to start the program sys.argv will
return the location of the link instead of the path to your
application file I think. Anyway you can get the directory of the
application file with sys.path if you need it.
However, why not just put all application files into one directory
(like /usr/local/share/yourApp or /opt/lib/myApp or something) and
start it from a link from /usr/local/bin (or /opt/bin) to your app's
main program file instead of messing around with sys.path , at least
it's the easiest solution and I don't really see the benefit of
putting the files into different directories unless you have modules
other people might want to use, in which case python's site-packages
directory would probably be the preferred location.
Just a personal opinion of course.
More information about the Python-list