I can't think about a potential security issue with that as long as you trust your default python interpreter...
So to sum up the workaround: Saving the following line as c:\Python38\Scripts\gdal_calc.bat (or as the same name as any other x.py script) @python %~dp0\%~n0.py %* and calling gdal_calc (apparently .bat has higher priority then .py) would work regardless of the py file association. For anyone who is not familiar with the quirks of windows batch files: @ = not to echo the command python = your default python interpreter %~dp0 means the path of the current batch file (i.e. c:\Python38\Scripts) %~n0 means the name of the batch file without extension (i.e. gdal_calc) So running gdal_calc it would essentially call the following: python c:\Python38\Scripts\gdal_calc.py Idan On Thu, 25 Feb 2021 at 12:02, Richard Duivenvoorde <rdmaili...@duif.net> wrote: > On 2/25/21 10:53 AM, Idan Miara wrote: > > Actually, it might be a good idea to use a batch file... > > > > I've created the following batch file named gdal_calc.bat in the scripts > folder: > > @python %~dp0\gdal_calc.py %* > > > > Then running gdal_calc works even if *.py is associated with PyCharm. > > Do you think this issue justifies creating this kind of batch files for > the scripts to distribute in binary windows wheels ? > > Mmm, /me no windows expert, I don't know. > > But couldn't this be a potential security issue? But I let knowledge to > Windows/Python packagers.... > > Regards, > > Richard Duivenvoorde >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
