getopt_long - option nicht ambiguous?

DeSoVoDaMu

Hi,
irgendwie macht getopt_long nicht das, was ich erwarte

while (1)
    {
        int option_index = 0;
        static struct option long_options[] =
        {
            {"test-1", 0, 0, 0},
            {"test-2", 0, 0, 0},
            {0, 0, 0, 0}
        };

        int c = getopt_long (argc, argv, "", long_options, &option_index);

        if (c == -1)
            break;

        switch (c)
        {
        case 0:
            printf ("option %s\n", long_options[option_index].name);
            break;
        }
    }

Es gibt also 2 lange Optionen, --test-1 und --test-2. Rufe ich das Programm jetzt mit --test auf, ist --test-1 die option, die ausgegeben wird (option_index wird auf 0 gesetzt / bleibt auf diesem wert). Aber das ist ansich nicht der Punkt. Der Punkt ist, dass keine Meldung kommt, dass diese Option mehrdeutig (ambiguous) ist, weil es ja --test-1 oder --test-2 sein koennte.
Aendere ich den Code so ab:

static struct option long_options[] =
        {
            {"test-1", 0, 0, 1}, // hier steht jetzt eine 1 am ende
            {"test-2", 0, 0, 0},
            {0, 0, 0, 0}
        };

kommte eine Meldung, wie man sie erhofft.
Aber die 1 ist der Wert val der option struct und dieser ist nichts weiter als der Rueckgabewert von getopt_long (in diesem Fall zumindest). Er hat laut man-page nichts mit der Ausgabe von Meldungen zu tun.
Die Optionen ansich werden korrekt einzeln erkannt. Das heisst starte ich das Programm mit --test-1 bzw. --test-2 werden die Optionen entsprechend ausgegeben.

Hat jemand eine Idee, warum im ersten Beispiel keine Meldung ausgegeben wird?

Gruss,
DeSoVoDaMu

PillePalle

Tipp: Werte doch die Parameter mit einer eigenen Funktion aus. Dann weiß du , wenn etwas schief geht worans liegt und lernst gliech noch etwas dazu

DeSoVoDaMu

Ich habe keine Lust das Rad staendig neu zu erfinden
Es wird doch wohl eine logische Erklaerung fuer das beschriebene Problem geben.

CStoll

Woran soll die Funktion auch die beiden Optionen unterscheiden? Du übergibst für beide den Wert 0, also sind sie aus Systemsicht auch identisch.

DeSoVoDaMu

Woran soll die Funktion auch die beiden Optionen unterscheiden?

An den Strings? Es steht doch nirgendwo, dass val als Vergleichswert genutzt wird und daher eindeutig zu sein hat.

man getopt_long schrieb:

val is the value to return, or to load into the variable pointed to
by flag.

Aber jetzt wo du es sagst ist das die einzige logische Erklaerung. Danke.
Gott, die Funktion wird mir immer unsympatischer...

Gruss,
DeSoVoDaMu

pale dog

http://www.math.utah.edu/tex-archive/dviware/dvi2bitmap/getopt_long.c
(die letzte funktion, unten, ist zum testen)
vielleicht hilfts...

DeSoVoDaMu

Ja eben diesem Beispiel war ja der obige Quellcode auch entsprungen.
Und dort hat val auch ueberall den Wert 0:

static struct option long_options[] =
      {
	{"add", 1, 0, 0}, // ueberall Nullen als letzter Wert
	{"append", 0, 0, 0},
	{"delete", 1, 0, 0},
	{"verbose", 0, 0, 0},
	{"create", 0, 0, 0},
	{"file", 1, 0, 0},
	{0, 0, 0, 0}
      };

Ich meine so geht es, wenn ich das Programm mit --a aufrufe (es kommt Meldung wegen Mehrdeutigkeit). Aendere ich aber add ab, dass es keinen Parameter mehr erwartet (1 wird zu 0) und starte das Programm mit --a, so kommt keine Meldung.
Es ist ja wohl durchaus legitim, dass 2 Parameter einen identischen Anfang haben und keine Argumente nehmen.
Wie dem auch sei...durch die Erkenntnis, wo der Fehler lag, konnte ich einen Workaround schreiben. Nichts desto trotz ist dieses Verhalten nirgendwo (wo ich geschaut habe) dokumentiert und SEHR verwirrend - imho sehr bugverdaechtig

PillePalle

So Schwireg ist das ja nun auch wieder nicht. Kannst das Parameter Array durchgehen und dann mit strcmp abgleichen und den Kontrollfluss beeinflussen.

DeSoVoDaMu

Was soll mir dieser Beitrag jetzt sagen, PillePalle?

PillePalle

Machs Selber und lerne . Nicht böse gemeint.

Gruß PillePalle