Telling python where to look for a script

[Bengt Richter]

On Thu, 14 Jun 2001 13:18:38 +0200, Brian Elmegaard
<brian at rk-speed-rugby.dk> wrote:

>
>
>Alex Martelli wrote:
>> 
>> the backslashes:-).  A module is meant to be imported.
>> A foo.py file can be both, but adapting the path is
>> relevant to module-use only, NOT to script-use.  All
>> clear so far...?
>> 
>No, I'm sorry.
>
>Being in c:\foo I would like to be able to execute bar.py on baz.dat
>being in . just by typing:
>
>c:\foo>python bar.py baz.dat
>
>Then I need something path-related with scripts, don't I?
If you're on windows, you should be able to type
	c:\foo>bar.py baz.dat
IOW, let the windows shell find python.exe for you when
it sees the '.py' on the 'bar'

Of course, bar.py must be on your windows PATH for it to
find that, and the .py file association must be set up,
but baz.dat will have to be in your current working
directory or you'll have to specify a full path, unless
your bar.py has a programmed search of its own to look
for baz.dat.

In my case, I'm on NT4sp3 and this shows the associations:
--
[12:35] C:\pywk>assoc .py
.py=Python.File

[12:35] C:\pywk>ftype Python.file
Python.file=D:\Python21\python.exe "%1" %*
--

The only trouble with this is that you won't be able to
redirect or pipe the output if you depend on the windows
shell to execute python for you. A PIT* windows 'feature'
that affects perl and other similar situations also.

For a specific  foo.py, you can wrap it in a foo.cmd
that exlicitly executes python with the args. Then
you can redirect the output of that as normal.E.g.,

@REM foo.cmd wrapper for foo.py
@python foo.py %*

You probably will want to put in full paths for python
and foo in the above.

HTH