Bartolomei.Chris wrote:
> While I think that there could have been a way to move forward with
> python and yet not break the legacy shell scripts users have when
> migrating, I understand the changes now.
If MSys treats other shell scripts as executables, one option might be
to auto-generate a
On Wed, May 4, 2016 at 7:37 PM, Bartolomei.Chris
wrote:
> I want to thank everyone for their feedback and information on this issue,
> you folks are awesome!
> While I think that there could have been a way to move forward with python
> and yet not break the legacy
I want to thank everyone for their feedback and information on this issue, you
folks are awesome!
While I think that there could have been a way to move forward with python and
yet not break the legacy shell scripts users have when migrating, I understand
the changes now.
I do have a
On Wed, May 4, 2016 at 12:01 PM, Moritz Lennert
wrote:
> On 04/05/16 00:50, Bartolomei.Chris wrote:
>>
>> Hi Martin
>> The problem I am having is that my bourne shell scripts (#!/bin/sh) cannot
>> execute the bat files ...
...
> As Helmut has tried to clarify, the
On 04/05/16 00:50, Bartolomei.Chris wrote:
Hi Martin
The problem I am having is that my bourne shell scripts (#!/bin/sh) cannot
execute the bat files ... the scripts call the GRASS modules by name i.e.
v.db.update map=stream_7 layer=3 column=block_col value="-1" --quiet
In GRASS 6.4.4 (with
>In GRASS 6.4.4 (with msys) I could just run the scripts and everything ran
fine.
in the move of GRASS6.x to GRASS7 scripts are changed from shell scripts [1]
to python scripts [2].
therefore some mechanism is needed to start these python scripts with the
right python interpreter (e.g. own
Hi Martin
The problem I am having is that my bourne shell scripts (#!/bin/sh) cannot
execute the bat files ... the scripts call the GRASS modules by name i.e.
v.db.update map=stream_7 layer=3 column=block_col value="-1" --quiet
In GRASS 6.4.4 (with msys) I could just run the scripts and
Bartolomei.Chris-2 wrote
> I attached a couple txt files (I hope they don't get striped off...)
> listing the GRASS modules in the "bin" directory - one lists all of the
> ".exe" modules and one lists all of the ".bat" modules. Why are there both
> formats? How are we supposed to run (shell)
2016-05-03 22:17 GMT+02:00 Bartolomei.Chris :
> I attached a couple txt files (I hope they don't get striped off...) listing
> the GRASS modules in the "bin" directory - one lists all of the ".exe"
> modules and one lists all of the ".bat" modules. Why are there both
I attached a couple txt files (I hope they don't get striped off...) listing
the GRASS modules in the "bin" directory - one lists all of the ".exe" modules
and one lists all of the ".bat" modules. Why are there both formats? How are we
supposed to run (shell) scripts calling the modules? It
>They modules should all be compiled executables so legacy shell >scripts
users have can run them ...
AFAIK there were always a distinction in GRASS between compiled code and
scripts since the beginning.
the motivation of the switch to python scripts from grass6 to grass7 was
cross platform
Ok (I guess) but this causes severe problems running shell scripts that call
out the GRASS modules ... there is no way of knowing which modules are compiled
executables (which run fine from the shell script) and which ones are Windows
Batch files (which DON'T run when called from a script) ...
Good evening and happy weekend!
I am (still) upgrading from 6.4.4 to 7.0.3 and I discovered that the vector
topography of all my data is not upwards compatible so per the instructions at
https://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7 I
am (trying) to us v.build.all
13 matches
Mail list logo