[GRASS-user] Running a Pyhton Script on Mac (Mapcalc)

[Glynn Clements]

William Kyngesburye wrote:

> 5. And, it's the Python interpreter that handles this, not GRASS.
> Though I guess it also depends how you run it.  If you run it with just
> the script name, the shell needs to find the #! before it passes it off
> to Python, so it might need the unix LF (and this is also not GRASS, but
> the shell).

According to recent versions of POSIX, it should be either the OS
kernel or the C library which handles scripts. Specifically, at least
execlp() and execvp() should be able to execute a script directly; the
other exec* functions (without the "p" suffix) may or may not support
scripts.

On Linux, it's the OS kernel (i.e. execve()) which deals with this, so
all of the exec* functions can execute scripts.

With early Unices, it was the shell which handled scripts. Typically,
if exec* failed with ENOEXEC, the shell would attempt to parse the #! 
line and invoke the script via its interpreter. The end result was
that scripts only work when executed via a shell. The only "current"
platform which works this way is MSys, where the shell has to
implement it because Windows doesn't.

Either way, neither Python nor GRASS have any control over the
situation.

> If you run the script from Python, 'python yourscript.py',
> then Python handles the script file completely.  I thought Python did
> handle all line endings, but I may be wrong.

Python supports "universal newlines"; when opening a file for read, if
the "mode" argument is "U" or "rU", any of '\n', '\r' or '\r\n' are
accepted as line terminators, and converted to '\n'.

However, this isn't relevant for the #! line, and only applies to
reading files from within Python. If you open a file from within
Python then pass the handle to a child process, the child process will
see the raw data.

-- 
Glynn Clements <glynn at gclements.plus.com>