Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On Tue, Jul 8, 2014 at 4:13 AM, Helmut Kudrnovsky hel...@web.de wrote: Anna Petrášová wrote On Sun, Jul 6, 2014 at 3:59 AM, Helmut Kudrnovsky lt; hellik@ gt; wrote: C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, li ne 58, in __init__ raise OSError OSError It's because gui doesn't reflect recent changes by Martin. I temporarily fixed it in r61171 but I don't really understand current status, is it still work in progress? By the way the Popen class should be changed according two Glynn's suggestions to let Popen throw the error. Anna tested with: System Info GRASS Version: 7.1.svn GRASS SVN Revision: 61180 Erstellungsdatum: 2014-07-08 Build Platform: i686-pc-mingw32 GDAL/OGR: 1.11.0 PROJ.4: 4.8.0 GEOS: 3.4.2 SQLite: 3.7.17 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-7-6.1.7601-SP1 (OSGeo4W) the GUI starts now, thanks. g.gui.* modules are not found, there is no bat file created for them. Could something similar to this be used for them as well? Otherwise everything seems to be working. http://trac.osgeo.org/grass/changeset/61136 Anna - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5150047.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Anna Petrášová wrote the GUI starts now, thanks. g.gui.* modules are not found, there is no bat file created for them. Could something similar to this be used for them as well? Otherwise everything seems to be working. http://trac.osgeo.org/grass/changeset/61136 Anna g.gui.* which are linked in the main GUI are starting, but can't be invoked in the wxGUI-command line. also again, python addon scripts needs again bat-files in windows. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5150331.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Anna Petrášová wrote On Sun, Jul 6, 2014 at 3:59 AM, Helmut Kudrnovsky lt; hellik@ gt; wrote: C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, li ne 58, in __init__ raise OSError OSError It's because gui doesn't reflect recent changes by Martin. I temporarily fixed it in r61171 but I don't really understand current status, is it still work in progress? By the way the Popen class should be changed according two Glynn's suggestions to let Popen throw the error. Anna tested with: System Info GRASS Version: 7.1.svn GRASS SVN Revision: 61180 Erstellungsdatum: 2014-07-08 Build Platform: i686-pc-mingw32 GDAL/OGR: 1.11.0 PROJ.4: 4.8.0 GEOS: 3.4.2 SQLite: 3.7.17 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-7-6.1.7601-SP1 (OSGeo4W) the GUI starts now, thanks. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5150047.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On Sun, Jul 6, 2014 at 3:59 AM, Helmut Kudrnovsky hel...@web.de wrote: Martin Landa wrote Hi, 2014-07-02 20:54 GMT+02:00 Martin Landa lt; landa.martin@ gt;: It's because it can't find v.in.gps. I suggest to add to the patch something like this: thanks, I included modified patch to the next build n1011. Martin seems to be set forward, committed as r61135, feel free to improve. Martin tested with: GRASS 7.1.svn g.version -g version=7.1.svn date=2014 revision=61158 build_date=2014-07-06 build_platform=i686-pc-mingw32 it fails with: Launching wxpython GUI in the background, please wait... GRASS 7.1.svn Traceback (most recent call last): File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 138, in module sys.exit(main()) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 131, in main app = GMApp(workspaceFile) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 45, in __init__ wx.App.__init__(self, False) File C:\OSGeo4W\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.p y, line 7981, in __init__ self._BootstrapApp() File C:\OSGeo4W\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.p y, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 79, in OnInit workspace = self.workspaceFile) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\lmgr\frame.py, line 12 1, in __init__ self._moduleTreeBuilder = LayerManagerModuleTree() File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\lmgr\menudata.py, line 62, in __init__ MenuTreeModelBuilder.__init__(self, filename, expandAddons=expandAddons) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\menutree.py, line 66, in __init__ expAddons(xmlTree) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\toolboxes.py, lin e 271, in expandAddons _expandAddonsItem(root) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\toolboxes.py, lin e 431, in _expandAddonsItem addons = _getAddons() File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\toolboxes.py, lin e 404, in _getAddons flags='a').splitlines()) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\gcmd.py, line 704 , in RunCommand ps = grass.start_command(GetRealCmd(prog), flags, overwrite, quiet, verbose, **kwargs) File C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, li ne 354, in start_command return Popen(args, **popts) File C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, li ne 58, in __init__ raise OSError OSError It's because gui doesn't reflect recent changes by Martin. I temporarily fixed it in r61171 but I don't really understand current status, is it still work in progress? By the way the Popen class should be changed according two Glynn's suggestions to let Popen throw the error. Anna - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5149811.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Hi, 2014-07-07 21:58 GMT+02:00 Anna Petrášová kratocha...@gmail.com: It's because gui doesn't reflect recent changes by Martin. I temporarily fixed it in r61171 but I don't really understand current status, is it still work in progress? By the way the Popen class should be changed according two Glynn's suggestions to let Popen throw the error. feel free to implement Glynn's suggestions. I do not have time to try to make WinGRASS 71 working again. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Martin Landa wrote Hi, 2014-07-02 20:54 GMT+02:00 Martin Landa lt; landa.martin@ gt;: It's because it can't find v.in.gps. I suggest to add to the patch something like this: thanks, I included modified patch to the next build n1011. Martin seems to be set forward, committed as r61135, feel free to improve. Martin tested with: GRASS 7.1.svn g.version -g version=7.1.svn date=2014 revision=61158 build_date=2014-07-06 build_platform=i686-pc-mingw32 it fails with: Launching wxpython GUI in the background, please wait... GRASS 7.1.svn Traceback (most recent call last): File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 138, in module sys.exit(main()) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 131, in main app = GMApp(workspaceFile) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 45, in __init__ wx.App.__init__(self, False) File C:\OSGeo4W\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.p y, line 7981, in __init__ self._BootstrapApp() File C:\OSGeo4W\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.p y, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 79, in OnInit workspace = self.workspaceFile) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\lmgr\frame.py, line 12 1, in __init__ self._moduleTreeBuilder = LayerManagerModuleTree() File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\lmgr\menudata.py, line 62, in __init__ MenuTreeModelBuilder.__init__(self, filename, expandAddons=expandAddons) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\menutree.py, line 66, in __init__ expAddons(xmlTree) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\toolboxes.py, lin e 271, in expandAddons _expandAddonsItem(root) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\toolboxes.py, lin e 431, in _expandAddonsItem addons = _getAddons() File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\toolboxes.py, lin e 404, in _getAddons flags='a').splitlines()) File C:\OSGeo4W\apps\grass\grass-7.1.svn\gui\wxpython\core\gcmd.py, line 704 , in RunCommand ps = grass.start_command(GetRealCmd(prog), flags, overwrite, quiet, verbose, **kwargs) File C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, li ne 354, in start_command return Popen(args, **popts) File C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, li ne 58, in __init__ raise OSError OSError - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5149811.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Vaclav Petras wrote: kwargs['shell'] = True args = [self._escape_for_shell(arg) for arg in args] Considering security issues connected to shell=True* and uncertainty of escaping for MS Windows**, wouldn't be better to avoid shell=True and try to use the right interpreter? This can work at least for the most common (and probably only important) case which is Python. That's an option. Although if we use .bat files to execute Python scripts, shutil_which() will find the .bat file rather than the script itself. If we hard-code the handling of Python scripts, it should only be done for those which are part of GRASS (i.e. where the script is located in a subdirectory of $GISBASE). We would still need to fall back to using the shell for other extensions. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Hi, 2014-07-02 20:54 GMT+02:00 Martin Landa landa.mar...@gmail.com: It's because it can't find v.in.gps. I suggest to add to the patch something like this: thanks, I included modified patch to the next build n1011. Martin seems to be set forward, committed as r61135, feel free to improve. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
2014-07-02 1:10 GMT+02:00 Glynn Clements gl...@gclements.plus.com: Does anyone want to test the attached patch? I have locally applied the patch on the build server, result is `r61114M-1010` [1], GRASS starts (welcome screen), unfortunately wxGUI fails with File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 138, n module sys.exit(main()) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 131, n main app = GMApp(workspaceFile) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 45, i __init__ wx.App.__init__(self, False) File C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core py, line 7981, in __init__ self._BootstrapApp() File C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\wxgui.py, line 79, i OnInit workspace = self.workspaceFile) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\lmgr\frame.py, line 19, in __init__ self._menuTreeBuilder = LayerManagerMenuData() File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\lmgr\menudata.py, li e 40, in __init__ MenuTreeModelBuilder.__init__(self, filename, expandAddons=expandAddons) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\menutree.py, li e 64, in __init__ xmlTree = etree.parse(filename) File C:\OSGEO4~1\apps\Python27\lib\xml\etree\ElementTree.py, line 1182, in arse tree.parse(source, parser) File C:\OSGEO4~1\apps\Python27\lib\xml\etree\ElementTree.py, line 657, in p rse self._root = parser.close() File C:\OSGEO4~1\apps\Python27\lib\xml\etree\ElementTree.py, line 1654, in lose self._raiseerror(v) File C:\OSGEO4~1\apps\Python27\lib\xml\etree\ElementTree.py, line 1506, in raiseerror raise err xml.etree.ElementTree.ParseError: no element found: line 1, column 0 The reason is empty XML wxGUI menu file (menudata.xml) produced by building system, see [2]. Traceback (most recent call last): File core/toolboxes.py, line 759, in module sys.exit(main()) File core/toolboxes.py, line 745, in main userDefined=False) File core/toolboxes.py, line 204, in createTree moduleItems=moduleItems) File core/toolboxes.py, line 241, in toolboxes2menudata _expandRuntimeModules(root) File core/toolboxes.py, line 514, in _expandRuntimeModules desc, keywords = _loadMetadata(name) File core/toolboxes.py, line 540, in _loadMetadata task = gtask.parse_interface(module) File c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\python\grass\script\task.py, line 501, in parse_interface tree = etree.fromstring(get_interface_description(name)) File c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\python\grass\script\task.py, line 465, in get_interface_description stderr = PIPE) File c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\python\grass\script\core.py, line 58, in __init__ name, ext = os.path.splitext(cmd) File c:/OSGeo4W/apps/Python27\lib\ntpath.py, line 190, in splitext return genericpath._splitext(p, sep, altsep, extsep) File c:/OSGeo4W/apps/Python27\lib\genericpath.py, line 91, in _splitext sepIndex = p.rfind(sep) AttributeError: 'NoneType' object has no attribute 'rfind' make[4]: *** [xml/menudata.xml] Error 1 Martin [1] http://wingrass.fsv.cvut.cz/grass71/ [2] http://wingrass.fsv.cvut.cz/grass71/logs/log-r61114-1010/package.log -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On Wed, Jul 2, 2014 at 10:39 AM, Martin Landa landa.mar...@gmail.com wrote: The reason is empty XML wxGUI menu file (menudata.xml) produced by building system, see [2]. Traceback (most recent call last): File core/toolboxes.py, line 759, in module sys.exit(main()) File core/toolboxes.py, line 745, in main userDefined=False) File core/toolboxes.py, line 204, in createTree moduleItems=moduleItems) File core/toolboxes.py, line 241, in toolboxes2menudata _expandRuntimeModules(root) File core/toolboxes.py, line 514, in _expandRuntimeModules desc, keywords = _loadMetadata(name) File core/toolboxes.py, line 540, in _loadMetadata task = gtask.parse_interface(module) File c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\python\grass\script\task.py, line 501, in parse_interface tree = etree.fromstring(get_interface_description(name)) File c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\python\grass\script\task.py, line 465, in get_interface_description stderr = PIPE) File c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\python\grass\script\core.py, line 58, in __init__ name, ext = os.path.splitext(cmd) File c:/OSGeo4W/apps/Python27\lib\ntpath.py, line 190, in splitext return genericpath._splitext(p, sep, altsep, extsep) File c:/OSGeo4W/apps/Python27\lib\genericpath.py, line 91, in _splitext sepIndex = p.rfind(sep) AttributeError: 'NoneType' object has no attribute 'rfind' make[4]: *** [xml/menudata.xml] Error 1 It seems that shutil_which returned None at line (from the patch): cmd = shutil_which(args[0]) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On Wed, Jul 2, 2014 at 11:19 AM, Anna Petrášová kratocha...@gmail.com
wrote:
On Wed, Jul 2, 2014 at 10:59 AM, Vaclav Petras wenzesl...@gmail.com
wrote:
On Wed, Jul 2, 2014 at 10:39 AM, Martin Landa landa.mar...@gmail.com
wrote:
The reason is empty XML wxGUI menu file (menudata.xml) produced by
building system, see [2].
Traceback (most recent call last):
File core/toolboxes.py, line 759, in module
sys.exit(main())
File core/toolboxes.py, line 745, in main
userDefined=False)
File core/toolboxes.py, line 204, in createTree
moduleItems=moduleItems)
File core/toolboxes.py, line 241, in toolboxes2menudata
_expandRuntimeModules(root)
File core/toolboxes.py, line 514, in _expandRuntimeModules
desc, keywords = _loadMetadata(name)
File core/toolboxes.py, line 540, in _loadMetadata
task = gtask.parse_interface(module)
File
c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\python\grass\script\task.py,
line 501, in parse_interface
tree = etree.fromstring(get_interface_description(name))
File
c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\python\grass\script\task.py,
line 465, in get_interface_description
stderr = PIPE)
File
c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\python\grass\script\core.py,
line 58, in __init__
name, ext = os.path.splitext(cmd)
File c:/OSGeo4W/apps/Python27\lib\ntpath.py, line 190, in splitext
return genericpath._splitext(p, sep, altsep, extsep)
File c:/OSGeo4W/apps/Python27\lib\genericpath.py, line 91, in
_splitext
sepIndex = p.rfind(sep)
AttributeError: 'NoneType' object has no attribute 'rfind'
make[4]: *** [xml/menudata.xml] Error 1
It's because it can't find v.in.gps. I suggest to add to the patch
something like this:
+def __init__(self, args, **kwargs):
+if ( sys.platform == 'win32'
+ and isinstance(args, list)
+ and not kwargs.get('shell', False)
+ and kwargs.get('executable') is None ):
+cmd = shutil_which(args[0])
if cmd is None:
raise OSError
+args = [cmd] + args[1:]
+name, ext = os.path.splitext(cmd)
+if ext.lower() not in self._builtin_exts:
+kwargs['shell'] = True
+args = [self._escape_for_shell(arg) for arg in args]
+subprocess.Popen.__init__(self, args, **kwargs)
Otherwise the patch seems to work, I can run:
grass.run_command('r.support', map='mymap', title=|@#~$%^*()) in GUI
python console which was not possible before. r.info then gives correct
result.
Running this command in gui console works but r.info gives incorrect result:
r.support map=scanned title=|@#$%^*()
and r.info gives ^^^|@#$%^^^*()
but gui command line functionality was not affected by this patch, it uses
different popen class, this is related to r60634 and following.
It seems that shutil_which returned None at line (from the patch):
cmd = shutil_which(args[0])
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Hi, 2014-07-02 17:19 GMT+02:00 Anna Petrášová kratocha...@gmail.com: It's because it can't find v.in.gps. I suggest to add to the patch something like this: thanks, I included modified patch to the next build n1011. Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Anna Petrášová wrote:
It's because it can't find v.in.gps. I suggest to add to the patch
something like this:
+def __init__(self, args, **kwargs):
+if ( sys.platform == 'win32'
+ and isinstance(args, list)
+ and not kwargs.get('shell', False)
+ and kwargs.get('executable') is None ):
+cmd = shutil_which(args[0])
if cmd is None:
raise OSError
+args = [cmd] + args[1:]
+name, ext = os.path.splitext(cmd)
+if ext.lower() not in self._builtin_exts:
+kwargs['shell'] = True
+args = [self._escape_for_shell(arg) for arg in args]
+subprocess.Popen.__init__(self, args, **kwargs)
Hmm; maybe:
def __init__(self, args, **kwargs):
if ( sys.platform == 'win32'
and isinstance(args, list)
and not kwargs.get('shell', False)
and kwargs.get('executable') is None ):
cmd = shutil_which(args[0])
if cmd is not None:
args = [cmd] + args[1:]
name, ext = os.path.splitext(cmd)
if ext.lower() not in self._builtin_exts:
kwargs['shell'] = True
args = [self._escape_for_shell(arg) for arg in args]
subprocess.Popen.__init__(self, args, **kwargs)
If shutil_which() doesn't find the command, we just leave it to
Popen() to complain about it. It's conceivable that it might even
manage to run it (I wouldn't assume that shutil_which() mimics
Windows' own handling exactly).
Ideally, I'd prefer our version of Popen to be as close to the
original as we can get away with.
Alternatively.
def __init__(self, args, **kwargs):
if ( sys.platform == 'win32'
and isinstance(args, list)
and not kwargs.get('shell', False)
and kwargs.get('executable') is None ):
cmd = shutil_which(args[0])
if cmd is not None:
args = [cmd] + args[1:]
name, ext = os.path.splitext(cmd)
else:
name, ext = None, ''
if ext.lower() not in self._builtin_exts:
kwargs['shell'] = True
args = [self._escape_for_shell(arg) for arg in args]
subprocess.Popen.__init__(self, args, **kwargs)
In this case, it falls back to using the shell if shutil_which()
fails, while still keeping the shell out of the way for an EXE.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Anna Petrášová wrote: Running this command in gui console works but r.info gives incorrect result: r.support map=scanned title=|@#$%^*() and r.info gives ^^^|@#$%^^^*() That implies that the GUI is escaping for the shell but then either not using the shell or overdoing the escaping. But I'm less concerned about the GUI than about the core grass.script functionality. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On Wed, Jul 2, 2014 at 7:35 PM, Glynn Clements gl...@gclements.plus.com wrote: kwargs['shell'] = True args = [self._escape_for_shell(arg) for arg in args] Considering security issues connected to shell=True* and uncertainty of escaping for MS Windows**, wouldn't be better to avoid shell=True and try to use the right interpreter? This can work at least for the most common (and probably only important) case which is Python. Vaclav * Now thinking about various WPS servers using GRASS, GIS systems using GRASS, and potential WebGRASS. ** It seems that it will be hard to guess how to do it. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
2014-06-09 11:01 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
beside remaining compilation errors [1], wingrass 71 still (after
weeks!!!) even doesn't start...
Traceback (most recent call last):
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py, line 31,
in module
from core import globalvar
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\globalvar.py, li
ne 29, in module
from core.debug import Debug
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py, line 6
6, in module
Debug = DebugMsg()
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py, line 3
7, in __init__
self.SetLevel()
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py, line 4
2, in SetLevel
self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 998, in gisenv
s = read_command(g.gisenv, flags='n')
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 400, in read_command
ps = pipe_command(*args, **kwargs)
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 375, in pipe_command
return start_command(*args, **kwargs)
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 334, in start_command
return Popen(args, **popts)
File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 711, in __init__
errread, errwrite)
File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 948, in _execute_chil
d
startupinfo)
Martin
[1] http://wingrass.fsv.cvut.cz/grass71/logs/log-r61085-1008/error.log
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On 1 July 2014 14:00, Martin Landa landa.mar...@gmail.com wrote:
2014-06-09 11:01 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
beside remaining compilation errors [1], wingrass 71 still (after
weeks!!!) even doesn't start...
Traceback (most recent call last):
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py, line
31,
in module
from core import globalvar
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\globalvar.py,
li
ne 29, in module
from core.debug import Debug
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py,
line 6
6, in module
Debug = DebugMsg()
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py,
line 3
7, in __init__
self.SetLevel()
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py,
line 4
2, in SetLevel
self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))
File
C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 998, in gisenv
s = read_command(g.gisenv, flags='n')
File
C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 400, in read_command
ps = pipe_command(*args, **kwargs)
File
C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 375, in pipe_command
return start_command(*args, **kwargs)
File
C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 334, in start_command
return Popen(args, **popts)
File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 711, in __init__
errread, errwrite)
File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 948, in
_execute_chil
d
startupinfo)
I just upload to a friend and it has the same problem :-(
Martin
[1] http://wingrass.fsv.cvut.cz/grass71/logs/log-r61085-1008/error.log
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Martin Landa wrote:
beside remaining compilation errors [1], wingrass 71 still (after
weeks!!!) even doesn't start...
Does anyone want to test the attached patch?
In particular, it needs to be tested with a Python script invoking an
exe with arguments containing characters which are likely to be
meaningful to the shell, including:
| % ^
d.text or r.support may be useful as test cases.
But in the longer term, should we be claiming to support a platform
for which we appear to have no active developers?
--
Glynn Clements gl...@gclements.plus.com
Index: lib/python/script/core.py
===
--- lib/python/script/core.py (revision 61080)
+++ lib/python/script/core.py (working copy)
@@ -41,8 +41,26 @@
class Popen(subprocess.Popen):
-pass
+_builtin_exts = set(['.com', '.exe', '.bat', '.cmd'])
+@staticmethod
+def _escape_for_shell(arg):
+# TODO: what are cmd.exe's parsing rules?
+return arg
+
+def __init__(self, args, **kwargs):
+if ( sys.platform == 'win32'
+ and isinstance(args, list)
+ and not kwargs.get('shell', False)
+ and kwargs.get('executable') is None ):
+cmd = shutil_which(args[0])
+args = [cmd] + args[1:]
+name, ext = os.path.splitext(cmd)
+if ext.lower() not in self._builtin_exts:
+kwargs['shell'] = True
+args = [self._escape_for_shell(arg) for arg in args]
+subprocess.Popen.__init__(self, args, **kwargs)
+
PIPE = subprocess.PIPE
STDOUT = subprocess.STDOUT
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
2014-06-07 18:28 GMT+02:00 Glynn Clements gl...@gclements.plus.com: [...] Right, anyway it's not the first time you broken Windows builds without any attempt to fix (or even attempt to understand what you broke - it requires that you at least install GRASS on your Windows machine). The last example which I can mention is the problem with calling python script from python script. I was forced to locally patch winGRASS 7 for several months to make it working (it was used by many of us in our lessons). From this perspective you simply don't care..., you just revert without proposing any other working solution. On Unix, you'd expect developers to just build from source. But on Windows, getting a development environment set up is a lot more effort, so having access to binaries is still useful for developers. Right, that was the main reason why I put quite a lot of energy and my time to create environment for producing daily builds for Windows. And you can guess, I am not Windows user. Why I spent my time on that including fixing some Windows-related bugs? The main reason is that GRASS project needs good support on Windows. I would prefer to spend my time on other more interesting issues, as you can probably guess. But you're the one hosting them (or not), so it's your call. Right, and try to guess why? Because nobody wanted to do that, so I did. Don't ask me to do more for Windows, and please don't break GRASS on this platform regularly as you are doing. It's simply not my call! The person who introduced the complete break [3] simply doesn't care. No, that's not true. However, my Windows system is still rather inadequate as a development platform (it does now have the base MinGW/MSys installation, but not the libraries required to build GRASS). Feel free to invest your time to make it better, just reverting or blocking is not the way. If you are not able to find such time, please tell us and don't continue reverting our attempts to make it working. It doesn't absolutely *have* to be me who fixes it. I don't even use Windows as a development platform for my own purposes. If Windows Huh, I know probably only one GRASS developer here who uses Windows regularly, other people use GNU/Linux. From this perspective we haven't had any daily builds on Windows, because nobody would set it up. The changes required to Script.make and/or ScriptRules.make to create batch files aren't exactly rocket science, but testing them would be much easier for someone who has a Windows system which can actually build GRASS. Cool, if you are reverting other attempts you could probably find some time to implement it even it's not exactly rocket science. The discussion about this topic has probably tens of e-mails with guessable result. You were proposed bat-files at the beginning, no consensus, no other way. Never ending discussions with no result. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On 05/06/14 21:14, Martin Landa wrote: Hi, 2014-06-05 17:36 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. I had the feeling that this was the consensus (or at least with lack of clear dissension) we had reached: consensus is somehow courageous to say, bearing in mind that Glynn simply reverts any other solution regardless that it breaks the whole GRASS on Windows (try to install 7.1, completely useless, even no answer, break is just OK). Well, someone need to implement it, even some of us are not probably happy about that, we need to take care about user scripts and so on. It's somehow funny, because 7.0 simply works (same was for 7.1 some days ago). Have you looked at the reason for Glynn's revert ? Do you have a better suggestion to solve the problem at hand ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Markus Neteler wrote: 1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That has the same issues as using shell=True, but at least it only applies in the case where we're executing a script. ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. 2. If we know that the program is a script, the interpreter can be specified explicitly (i.e. python path/to/script.py). This keeps the shell out of the picture. ... how much effort is the latter? Check file type and path to file? No. The latter involves the caller knowing that it's invoking a script and explcitly invoking it via the interpreter. Attempting to determine this within the library is problematic, as we would need to mimic the mechanisms which the platform uses for invoking scripts. E.g. * If the program argument isn't a full path, we need to scan %PATH% for it. * If it lacks an extension, we also need to scan %PATHEXT%. * There's also the question of whether such treatment should be applied for any script, or just those which are part of GRASS. Using batch files has the advantage that we can just execute the command without worrying about any of this. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Martin Landa wrote: ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. I had the feeling that this was the consensus (or at least with lack of clear dissension) we had reached: consensus is somehow courageous to say, bearing in mind that Glynn simply reverts any other solution regardless that it breaks the whole GRASS on Windows The reason I do this is because GRASS has a long history of dealing with bugs using ugly hacks, which typically introduce equal-but-opposite bugs. This then means that any attempt to fix the underlying bug breaks everything. It also results in incomplete fixes, which are then fixed further by adding yet more code, with each iteration getting progressively uglier due to interactions with earlier layers. If something doesn't actually work, I'd rather everyone be aware of that and try to find an actual solution, rather than just papering over the cracks and pretending that the issue has been solved. E.g. if run_command() has problems with using a vertical bar character in an argument, modifying specific cases to avoid using a vertical bar doesn't fix the actual problem. Removing the shell from the equation fixes the actual problem (and possibly other problems related to the shell, e.g. ANSI-vs-OEM codepage issues). Escaping arguments should fix that specific problem (but not others), provided that we can accurately determine the shell's rules (Good Luck With That; the bash manual runs to ~82 pages; I've never seen anything like that for cmd.exe). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On 04/06/14 22:35, Markus Neteler wrote: On Wed, Jun 4, 2014 at 7:56 PM, Glynn Clements gl...@gclements.plus.com wrote: ... So either: 1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That has the same issues as using shell=True, but at least it only applies in the case where we're executing a script. ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. I had the feeling that this was the consensus (or at least with lack of clear dissension) we had reached: http://lists.osgeo.org/pipermail/grass-dev/2014-April/068519.html Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Hi, 2014-06-05 17:36 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. I had the feeling that this was the consensus (or at least with lack of clear dissension) we had reached: consensus is somehow courageous to say, bearing in mind that Glynn simply reverts any other solution regardless that it breaks the whole GRASS on Windows (try to install 7.1, completely useless, even no answer, break is just OK). Well, someone need to implement it, even some of us are not probably happy about that, we need to take care about user scripts and so on. It's somehow funny, because 7.0 simply works (same was for 7.1 some days ago). Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
2014-06-03 9:10 GMT+02:00 Pietro peter.z...@gmail.com: Remove Popen() magic on Windows; it creates more problems than it solves Please, could you explain which problems creates? I am waiting for reasonable/acceptable explanation for long time, I do not assume that it will ever come. Anyway, dear all, this commit completely broke the whole winGRASS 7.1 which even doesn't start File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 981, in gisenv s = read_command(g.gisenv, flags='n') File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 400, in read_command ps = pipe_command(*args, **kwargs) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 375, in pipe_command return start_command(*args, **kwargs) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 334, in start_command return Popen(args, **popts) File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 711, in __init__ errread, errwrite) File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 948, in _execute_chil d startupinfo) WindowsError: [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor Error in GUI startup. If necessary, please report this error to the GRASS develo pers. Switching to text mode now. Hit RETURN to continue... Happily we have 7.0 which still includes this magic (in other words GRASS starts and works). Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Martin Landa wrote 2014-06-03 9:10 GMT+02:00 Pietro lt; peter.zamb@ gt;: Remove Popen() magic on Windows; it creates more problems than it solves Please, could you explain which problems creates? I am waiting for reasonable/acceptable explanation for long time, I do not assume that it will ever come. Anyway, dear all, this commit completely broke the whole winGRASS 7.1 which even doesn't start File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 981, in gisenv s = read_command(g.gisenv, flags='n') File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 400, in read_command ps = pipe_command(*args, **kwargs) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 375, in pipe_command return start_command(*args, **kwargs) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 334, in start_command return Popen(args, **popts) File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 711, in __init__ errread, errwrite) File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 948, in _execute_chil d startupinfo) WindowsError: [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor Error in GUI startup. If necessary, please report this error to the GRASS develo pers. Switching to text mode now. Hit RETURN to continue... Happily we have 7.0 which still includes this magic (in other words GRASS starts and works). Martin -- I don't understand this uneeded break of winGRASS 7.1. anyway, I've intensely tested this magic quite a lot in the last 2 months in different win-boxes (vista, 7, 8) with a bunch of different python scripts. no problem so far. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5144069.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Pietro wrote: Reminder for all Windows users, please note that winGRASS 7.1 no.981 will be broken (calling python script from python script issue - eg. wxGUI Extension manager) again. 2014-06-03 7:24 GMT+02:00 svn_gr...@osgeo.org: Author: glynn Date: 2014-06-02 22:24:32 -0700 (Mon, 02 Jun 2014) New Revision: 60679 Modified: grass/trunk/lib/python/script/core.py Log: Remove Popen() magic on Windows; it creates more problems than it solves Please, could you explain which problems creates? The shell doesn't simply pass its arguments to the program being executed; it may interpret them (e.g. performing redirection in the presence of |, or characters). For a specific example of why this is a problem, see ticket #2314. http://trac.osgeo.org/grass/ticket/2314 The quoting performed by the subprocess module (specifically, the list2cmdline() function) doesn't take this into account (i.e. it doesn't perform any additional quoting when shell=True). So either: 1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That has the same issues as using shell=True, but at least it only applies in the case where we're executing a script. 2. If we know that the program is a script, the interpreter can be specified explicitly (i.e. python path/to/script.py). This keeps the shell out of the picture. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On Wed, Jun 4, 2014 at 7:56 PM, Glynn Clements gl...@gclements.plus.com wrote: ... So either: 1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That has the same issues as using shell=True, but at least it only applies in the case where we're executing a script. ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. 2. If we know that the program is a script, the interpreter can be specified explicitly (i.e. python path/to/script.py). This keeps the shell out of the picture. ... how much effort is the latter? Check file type and path to file? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
2014-06-04 22:35 GMT+02:00 Markus Neteler nete...@osgeo.org:
2. If we know that the program is a script, the interpreter can be
specified explicitly (i.e. python path/to/script.py). This keeps the
shell out of the picture.
... how much effort is the latter? Check file type and path to file?
this check has been removed from thunk [1].
...
fcmd = get_real_command(args[0])
if fcmd.endswith('.py'):
Martin
[1]
http://trac.osgeo.org/grass/changeset/60679/grass/trunk/lib/python/script/core.py
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Reminder for all Windows users, please note that winGRASS 7.1 no.981
will be broken (calling python script from python script issue - eg.
wxGUI Extension manager) again.
2014-06-03 7:24 GMT+02:00 svn_gr...@osgeo.org:
Author: glynn
Date: 2014-06-02 22:24:32 -0700 (Mon, 02 Jun 2014)
New Revision: 60679
Modified:
grass/trunk/lib/python/script/core.py
Log:
Remove Popen() magic on Windows; it creates more problems than it solves
Modified: grass/trunk/lib/python/script/core.py
===
--- grass/trunk/lib/python/script/core.py 2014-06-03 03:51:54 UTC (rev
60678)
+++ grass/trunk/lib/python/script/core.py 2014-06-03 05:24:32 UTC (rev
60679)
@@ -41,28 +41,8 @@
class Popen(subprocess.Popen):
+pass
-def __init__(self, args, bufsize=0, executable=None,
- stdin=None, stdout=None, stderr=None,
- preexec_fn=None, close_fds=False, shell=None,
- cwd=None, env=None, universal_newlines=False,
- startupinfo=None, creationflags=0):
-
-if shell == None:
-shell = (sys.platform == win32)
-if sys.platform == win32:
-# get full path including file extension for scripts
-fcmd = get_real_command(args[0])
-if fcmd.endswith('.py'):
-args[0] = fcmd
-args.insert(0, sys.executable)
-
-subprocess.Popen.__init__(self, args, bufsize, executable,
- stdin, stdout, stderr,
- preexec_fn, close_fds, shell,
- cwd, env, universal_newlines,
- startupinfo, creationflags)
-
PIPE = subprocess.PIPE
STDOUT = subprocess.STDOUT
___
grass-commit mailing list
grass-com...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Hi Glynn, On Tue, Jun 3, 2014 at 8:55 AM, Martin Landa landa.mar...@gmail.com wrote: Reminder for all Windows users, please note that winGRASS 7.1 no.981 will be broken (calling python script from python script issue - eg. wxGUI Extension manager) again. 2014-06-03 7:24 GMT+02:00 svn_gr...@osgeo.org: Author: glynn Date: 2014-06-02 22:24:32 -0700 (Mon, 02 Jun 2014) New Revision: 60679 Modified: grass/trunk/lib/python/script/core.py Log: Remove Popen() magic on Windows; it creates more problems than it solves Please, could you explain which problems creates? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
