I’ve identified why r.recode was not recognizing the last term of the last recode rule. It needs a newline (\n) after the last recode rule in order to read all terms.
I don’t think it worked like that before, but it is not a problem once you know what to do. I’ve modified both the wxPython and TclTk GUI’s for rules entry to add a newline to r.recode rules and it all works fine.
Michael
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
I've identified why r.recode was not recognizing the last term of the
last recode rule. It needs a newline (\n) after the last recode rule
in order to read all terms.
I don't think it worked like that before, but it is not a problem once
you know what to do. I've modified both the wxPython and TclTk GUI's
for rules entry to add a newline to r.recode rules and it all works
fine.
The first task is to change the fgets() call in r.recode/read_rules.c to
G_getl2(). Then see if the bug is still there. G_getl2() doesn't store the
newline but fgets() does.
if (isatty(fileno(fp))) fprintf (stderr,"> ");
if (!fgets(buf,1024,fp)) return nrules;
buf[strlen(buf)-1] = '\0';
// ^^^ chops off the newline char using a blind brute force method.
// if fgets() ended because of EOF, the last char is real data.
for (n=0;buf[n];n++)
if(buf[n] == ',')
buf[n] = ' ';
G_strip(buf);
if (*buf == 0) continue;
if (*buf == '#') continue;
if (strcmp(buf, "end") == 0) break;