[GRASSLIST:4548] Re: Advice on changing source code for
R.A.Sanderson at newcastle.ac.uk
Fri Sep 20 10:11:11 EDT 2002
Dear Glynn -
Many thanks for the advice. When you suggest that it would be much more
efficient to use G_get_window() directly to abstract the region
information, am I right in assuming that you are recommending a programming
approach similar to that in the r.example code I've just discovered on the
GRASS website, which I see you've co-authored? What's confusing me a
little bit is that when I run gmake5 on the r.example code, it assumes I
have write access permission to the main grass5 /etc/bin/cmd directory,
which of course a non-administrator cannot write to. What should an
ordinary user do? Sorry - I guess I'm showing my ignorance here, but this
approach of interfacing GRASS to user-written C programs is new to me.
At 12:45 20/09/02 +0100, Glynn Clements wrote:
>Roy Sanderson wrote:
>> The observant amongst you will spot that east and west have swapped round.
>> As my colleagues have the g.region command liberally embedded in various
>> scripts, and the output is read by their own C programs, this is causing
>> problems. My suggestion to them that they should go through all their C
>> programs and edit the input lines was not well received!
>> As an alternative, I'm wondering whether to alter the Grass 5.0 code
>> myself, and recompile it. I've not done this before, but assume the
>> offending lines are in
>> /src/grass5.0.0pre5/src/general/g.region/cmd/printwindow.c Am I safe in
>> simply swapping the fprintf lines round for east and west so that they
>> match the Grass4.3 format, and re-compiling?
>IOW, it's unlikely that anything in GRASS relies upon the format;
>however, I'm not about to perform exhaustive analysis, and I doubt
>that anyone else is either.
>To elaborate slightly:
>It's safe to assume that nothing which is written in C will attempt to
>parse the output from "g.region -p", as it's vastly simpler to just
>use G_get_window() directly.
>Some scripts may parse the output from "g.region -p", but the only one
>which I've found (3d.view.sh) looks for the strings "north", "south"
>etc rather than relying upon the order.
>One final point: while the change in question is probably accidental
>(and unnecessary), the output format of GRASS programs should not be
>considered a defined interface, and may change in future versions.
>While such changes are unlikely to be made gratuitously, backward
>compatibility isn't the only consideration. E.g. it's entirely
>conceivable that the output from future versions of g.region may
>include additional information.
>Glynn Clements <glynn.clements at virgin.net>
More information about the grass-user