Check if module options are given more than once

[PaulWessel]

This is a possible solution to the issue discussed in #5604. If you build and run this command you can see the solution in action:

echo 0 0 1 | gmt xyz2grd -R-1/1/-1/1 -I1 -Gout.nc -Af -An

Currently, we mostly accept repeated module options (other than GMT common options) and that is bad since there is no feedback to the user, and there is no way to know which entry the user wanted. There are two solutions here:

1. As for repeated -R -R or -X -X, we shall give an error, as in this PR test.
2. Alternatively, we only make this situation warrant a warning and move on as before.

I am open to thoughts on this, @GenericMappingTools/core, but as users can turn off warnings I think an error is cleaner (since it is an error).

[PaulWessel]

Anyone have any thoughts or opinions on this one?

[seisman]

The solution looks good to me, but I doubt that someone can write a clever Python script or C program to do the job.

[PaulWessel]

The solution looks good to me, but I doubt that someone can write a clever Python script or C program to do the job.

Game on, @seisman!

[PaulWessel]

Not a script, but this should do. Will have to manually override the very few places (e.g., -G in grdtrack) where repeated options are allowed:

#include <stdio.h>
#include <string.h>
#include <ctype.h>

int main () {
	char line[512] = {""};
	int on = 0;

	while (fgets (line, 512, stdin)) {
		printf ("%s", line);
		if (!strncmp (line, "static int parse", 16U)) on = 1;
		else if (on && line[0] == '}') on = 0;
		if (on && !strncmp (line, "			case '", 9U) && strchr ("><", line[9]) == NULL && isupper (line[9])) {
			printf ("				n_errors += gmt_M_repeated_module_option (API, Ctrl->%c.active);\n", line[9]);
		}
	}
}

[PaulWessel]

This PR concludes my initial goal: to ensure that giving unique module options more than once will yield an error. I used the C code above to do most of the lifting. There were a few more corner cases that I forgot: We have many cases that are deprecated so there is no Ctrl->?.active variable for those. We also had options that can be repeated with different directives (say, -Lu and -Ll in surface) and these now have separate active[] items. Thus the manual fixing took a bit longer than I thought. Also, because I now define struct GMTAPI_CTRL *API = GMT->parent; in all the parse functions I also replaced the use of GMT->parent with API in those functions as well, such as in GMT_Report calls.

The update thus affected almost every single module code. A few options did not have a bool active in the structure, so now they all do. Once all this was implemented there were failures due to my coding errors, but finally only failures due to errors in scripts (actual duplicate options). Because of this, it is possible that commands generated by external wrappers could have similar bugs that so far would have gone undetected.

As an example of what happens with a duplicate option, see this:

gmt coast -R0/10/0/10 -JM5i -Baf -Gred -W0.5p -Gblue -png t 
coast [ERROR]: Option -G: Given more than once (offending option is -Gblue)

All tests pass. I suggest @meghanrjones and @joa-quim test this branch with PyGMT and GMT.jl to ensure that any problems are not in GMT but on the wrappers, and we can then approve and merge.

[maxrjones]

PyGMT tests pass.

[PaulWessel]

Let me know if any issues with Julia tests, @joa-quim .

[joa-quim]

So far no problems, tests pass, but I'm certain this will cause me some grief in future.

[PaulWessel]

Thanks. But think of it as better checking and you will be notified right away if you are coding something up incorrectly! Care to approve? Meghan is off this weekend.

[joa-quim]

Na. I actually would prefer that complicated options could be broken in pieces like -B.