[GRASS-dev] winGRASS: PATHEXT question

GRASS GIS GRASS GIS developer
1

Hi all,

when working with CLI (sh.exe) in winGRASS7, I am able to launch C-modules, eg.

r.buffer2

but not a python script

r.buffer -> command not found

The user has to type

r.buffer.py

I have checked $PATHEXT which contains beside EXE also PY extension.
The problem is that sh.exe ignores PATHEXT, right?

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

2

Martin wrote:

when working with CLI (sh.exe) in winGRASS7, I am
able to launch C-modules, eg.
r.buffer2

but not a python script
r.buffer -> command not found

The user has to type
r.buffer.py

I have checked $PATHEXT which contains beside EXE
also PY extension.
The problem is that sh.exe ignores PATHEXT, right?

I'm pretty sure that is correct, PATHEXT is only
recognized by DOS & cmd.exe

if sh.exe (bash) does too it will only be because
the MinGW folks have added custom support for it.
but I would guess that they won't have done that.

Hamish

3

Hamish wrote:

> I have checked $PATHEXT which contains beside EXE
> also PY extension.
> The problem is that sh.exe ignores PATHEXT, right?

I'm pretty sure that is correct, PATHEXT is only
recognized by DOS & cmd.exe

Right. But note that "cmd.exe" doesn't just mean running cmd.exe
interactively in a console window, but also C's system() and popen(),
Python's subprocess.Popen(), Windows' ShellExecute(), etc.

If the .py extension is removed, bash will still recognise it as a
script via the shebang, but native Windows APIs won't be able to
execute it.

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

4

Hi,

2011/12/4 Glynn Clements <glynn@gclements.plus.com>:

> I have checked $PATHEXT which contains beside EXE
> also PY extension.
> The problem is that sh.exe ignores PATHEXT, right?

I'm pretty sure that is correct, PATHEXT is only
recognized by DOS & cmd.exe

Right. But note that "cmd.exe" doesn't just mean running cmd.exe
interactively in a console window, but also C's system() and popen(),
Python's subprocess.Popen(), Windows' ShellExecute(), etc.

If the .py extension is removed, bash will still recognise it as a
script via the shebang, but native Windows APIs won't be able to
execute it.

I was thinking rather to "hide" the extensions, similarly to
exe-files. In other words, when you type in console window

r.buffer

the python script `r.buffer.py` will be launched. The user doesn't
care if the module is an exe-file or python-script. Probably BAT
script could help(?)

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

5

Martin Landa wrote:

> If the .py extension is removed, bash will still recognise it as a
> script via the shebang, but native Windows APIs won't be able to
> execute it.

I was thinking rather to "hide" the extensions, similarly to
exe-files. In other words, when you type in console window

r.buffer

the python script `r.buffer.py` will be launched. The user doesn't
care if the module is an exe-file or python-script. Probably BAT
script could help(?)

Only if MSys does some "magic" for BAT; Only EXE gets special
treatment from the OS. Specifically, if CreateProcess() is passed a
command line without a program, the first token in the command line is
taken as the program name. If the program name doesn't have an
extension, ".exe" is appended automatically. Any other extension (e.g.
.bat or .com) must be given explicitly. It's the shell (i.e. cmd.exe)
which uses PATHEXT to search for files with other extensions.

In any case, GRASS itself should be designed around the native
interfaces; on Windows, that means cmd.exe. Any support for MSys
should be done so as not to interfere with that. One option would be
to use shell aliases for scripts, i.e. "alias r.buffer=r.buffer.py".
Another would be to install shell scripts which execute the Python
script with its extension (i.e. the opposite of what we do for shell
scripts in 6.x).

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

6

hi,

when working with CLI (sh.exe) in winGRASS7, I am able to launch C-modules,

eg.

r.buffer2

but not a python script

r.buffer -> command not found

The user has to type

r.buffer.py

I have checked $PATHEXT which contains beside EXE also PY extension.
The problem is that sh.exe ignores PATHEXT, right?

some more here in
http://trac.osgeo.org/grass/ticket/1101

Helmut

--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/winGRASS-PATHEXT-question-tp7058942p7064564.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

7

[...] Probably BAT
script could help(?)

see also thread around
http://osgeo-org.1803224.n2.nabble.com/WinGrass6-5-svn-installer-with-selected-addons-td6873977.html#a6918034

i tested manually created bat-wrappers for py-scripts, it seems to work.

Helmut

--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/winGRASS-PATHEXT-question-tp7058942p7064609.html
Sent from the Grass - Dev mailing list archive at Nabble.com.