[GRASS5] saving command line meta-data for raster maps

[Hamish]

Hi,

I'd like to have another try at adding this library function or
something like it. Mostly because the output of eg r.patch stores no
history information, and that can be important when you want to go back
and try to figure out what the hell you did once it is gone from
.bash_history.

So this is G_command_history() and would live in lib/gis/history.c.
I don't claim that it is very good, but it is somewhat functional.
(need to update it to use #DEFINEs etc before going into CVS, etc)
Posting it now to get it into the archives.

Calling it would add the command line to the raster's hist file, as
Vect_hist_command(), "v.info -h" will display for vector maps.
Some raster modules (r.mapcalc, r.sun, v.surf.rst) already add some info
to the hist file. This would compliment that.

The raster hist/ file has major limitations though, so we have to do
some cutting up into multiple lines.\

Probably better to implement line-by-line writing to the history file
first, then use that (as the vector lib does). But I think the hist part
of raster maps should be majorly reworked & extended anyway[*], so we
should define what that is going to be before going to a lot of trouble
writing fns for the existing setup which will just have to be rewritten.

[*] see next email for suggested timing


thoughts?

Hamish


old message to Markus with original (circa 5.0.3) code is attached.
=================================================================

From: Hamish <hamish_nospam yahoo com>
Subject: Re: [GRASS-CVS] hamish: grass/src/raster/r.sun main.c,1.17,1.18
Date: Tue, 12 Aug 2003 00:18:10 +1200
To: "Markus Neteler" <neteler itc it>

> > As far as I remember, the history/comments structure is limited to
> > 80x24, so we'd have to check for commands like r.patch, r.series
> > which can have very long command lines.
> > Any reason for breaking at column 63 and not 76 or something bigger?
> 
> Ah, sorry - I was just guessing (somewhere in GRASS is a 63 chars
> restriction - anyway).

Ok, looking into it, it isn't 80x24 either, it's 80x50. The old 5.0
programmers' manual says it is 80x25 in section 12.21.4, but
include/gis.h says:

#define MAXEDLINES  50
#define RECORD_LEN  80
[...]
struct History
{
    char    mapid[RECORD_LEN];
    char    title[RECORD_LEN];
    char    mapset[RECORD_LEN];
    char    creator[RECORD_LEN];
    char    maptype[RECORD_LEN];
    char    datsrc_1[RECORD_LEN];
    char    datsrc_2[RECORD_LEN];
    char    keywrd[RECORD_LEN];
    int     edlinecnt;
    char    edhist[MAXEDLINES][RECORD_LEN];
};

r.info's "report" style makes target RECORD_LEN effectively a little
smaller to account for the | edges and still look good on standard
terminals (about 72 columns).


> Great, thanks. It is a longstanding wish to have that function...

see attached.
(needs string.h but libes/gis/history.c already has that)

I've got another version with some line wrapping at whitespace if you
want to play around with it; it works, but it is a pain: it looks good
to indent secondary lines, but that breaks really long input statements
(eg r.patch). Having some indented, some not looks horrible. Deciding
indent or no indent halfway adds pre-proccessing loops, table lookups,
ugg..

[...]


Hamish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Command_history.c
Type: text/x-csrc
Size: 2612 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20051031/a574eed8/Command_history.bin