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

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

(attachments)

Command_history.c (2.55 KB)

On Oct 31, 2005, at 1:10 AM, I wrote:

http://thread.gmane.org/gmane.comp.gis.grass.devel/9372

Added G_command_history(), for appending the (parsed) command line to
newly created raster maps' history files.

e.g r.patch badly needed this meta-info as you had no record of what went
into it after the .bash_history had faded.

also removed G_edit_history() from gisdefs.h as AFAICT it doesn't exist
in GRASS 5 or 6.

updated r.in.mat, r.patch, r.series, r.sun to use G_command_history().

hopefully it isn't too buggy,
Hamish