hpw to convert a linux python script ?

[Stef Mientki]

hello,

I've a python script, written for some Linux version,
now I want to run it under windows.
It complains of not finding files in
/usr/share/tinybldLin/ ....
where .... is the directory where the script is located and started from.

As there are a whole lot of these lines, in a whole lot of files,
I wonder if there's a simple trick to point
/usr/share/tinybldLin/
to my directory ?


thanks,
Stef

 

[Alec Schueler]

As there are a whole lot of these lines, in a whole lot of files,
I wonder if there's a simple trick to point
  /usr/share/tinybldLin/
to my directory ?

thanks,
Stef

Find and replace?

 

[Stef Mientki]

Find and replace?

well I was thinking of a more elegant way,
so the scripts remains, or better become multi-platform.

anyway thanks,
Stef

 

[rdmurray]

well I was thinking of a more elegant way,
so the scripts remains, or better become multi-platform.

anyway thanks,

Well, you'll have to rewrite the script so that it doesn't make
assumptions about path names, and we can't help you with that without
seeing some of the script code. There _might_ be easy fixes, but if the
path is hardcoded in many places in the script...then you will just have
to go through and un-hard-code it.

--RDM

 

[John Machin]

well I was thinking of a more elegant way,
so the scripts remains, or better become multi-platform.

Your current setup is not even single-platform portable ... consider
the scenario where some Linux admin wants your gear to live in some
directory other than /usr/share/tinybldLin/

The standard technique for ensuring that kind of portability involves:
1. Find the directory in which your script lives. Inspect sys.argv[0],
use some os.path.some_functionality() to extract the directory, name
it (say) home_base.
2. When you want to open a data file in the script's directory, do
this:
the_path = os.path.join(home_base, 'stef1.dat')
f = open(the_path, .....)

NOTE: Use os.path.join() instead of some DIY technique; it knows
better than you what the path separator is on the OS it's being run
on. In fact, read the whole of the os.path manual carefully before you
jump in to changing your code.

If you prefer to have the data files in (say) .../script_locn/data
instead of .../script_locn, the adjustment should be obvious.

Unfortunately, you are still going to need use find and replace to fix
your script. Code in haste, repent at leisure

HTH,
John

 

[Steve Holden]

well I was thinking of a more elegant way,
so the scripts remains, or better become multi-platform.

Your current setup is not even single-platform portable ... consider
the scenario where some Linux admin wants your gear to live in some
directory other than /usr/share/tinybldLin/

The standard technique for ensuring that kind of portability involves:
1. Find the directory in which your script lives. Inspect sys.argv[0],
use some os.path.some_functionality() to extract the directory, name
it (say) home_base.
2. When you want to open a data file in the script's directory, do
this:
the_path = os.path.join(home_base, 'stef1.dat')
f = open(the_path, .....)

NOTE: Use os.path.join() instead of some DIY technique; it knows
better than you what the path separator is on the OS it's being run
on. In fact, read the whole of the os.path manual carefully before you
jump in to changing your code.

If you prefer to have the data files in (say) .../script_locn/data
instead of .../script_locn, the adjustment should be obvious.

Unfortunately, you are still going to need use find and replace to fix
your script. Code in haste, repent at leisure

Of course the real issue here is that the same hard-coded directory name
(or possibly multiple directory names all rooted in the same directory)
are scattered throughout the program. Your (the OP's) first task should
be to store that "root" directory in a variable and then use the
variable in place of all current uses of the root directory.

For example, I have a Django project that I like to run under both
Windows and Cygwin. So in my settings.py file I have:

# Django settings for PyTeach project.
import sys
if sys.platform == 'cygwin':
fsroot = "/home/sholden"
elif sys.platform == 'win32':
fsroot = "C:/Users/sholden/Documents"
else:
sys.exit("Only configured for Windows and Cygwin")

Than further down I have

# Absolute path to the directory that holds media.
# Example: "/home/media/media.lawrence.com/"
MEDIA_ROOT = fsroot+'/Projects/PytDj/images/'

Note that most Windows APIs allow you to use the forward slash as a
delimiter. It's mostly the command line and Windows Explorer that are
snotty about insisting on the backslash.

regards
Steve

 

[Stephen Hansen]

# Absolute path to the directory that holds media.

# Example: "/home/media/media.lawrence.com/"
MEDIA_ROOT = fsroot+'/Projects/PytDj/images/'

Note that most Windows APIs allow you to use the forward slash as a
delimiter. It's mostly the command line and Windows Explorer that are
snotty about insisting on the backslash.

Idle curiosity, why do you prefer that to:

MEDIA_ROOT = os.path.join(fsroot, 'Projects', 'PytDj', 'images')

Not arguing that one is actually better then the other, just curious.

In my own environment we have grown a whole big filesystem abstraction
layer because we have to be able to address the same resources on
network volumes in the same client on multiple OS's (mainly windows
and mac presently, but a linux client has long been a
consideration),... and on the mac having to sometimes use mac paths
(":this:thatther") and sometimes posix paths ("/this/that/other")
depending on what API layer I'm poking at in a given point of view...
so personally I just end up being mildly curious how everyone else
handles paths and such.

Cuz it was quite a bit of a pain early on.

--S

 

[Steve Holden]

Idle curiosity, why do you prefer that to:

MEDIA_ROOT = os.path.join(fsroot, 'Projects', 'PytDj', 'images')

Not arguing that one is actually better then the other, just curious.

Going for "good enough", I suppose. It's more readable, at least, not
that that makes a *huge* difference.

In my own environment we have grown a whole big filesystem abstraction
layer because we have to be able to address the same resources on
network volumes in the same client on multiple OS's (mainly windows
and mac presently, but a linux client has long been a
consideration),... and on the mac having to sometimes use mac paths
(":this:thatther") and sometimes posix paths ("/this/that/other")
depending on what API layer I'm poking at in a given point of view...
so personally I just end up being mildly curious how everyone else
handles paths and such.

Cuz it was quite a bit of a pain early on.

The old Mac paths would indeed require your solution, which is strictly
speaking the best.

regards
Steve