[GRASSLIST:4548] Re: Advice on changing source code for g.region command

[Roy Sanderson]

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.

Best wishes
Roy

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?
>
>Probably.
>
>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>
>
>
>