Re: [bug-grep] Re: [Fwd: [Fwd: grep v2.5.1]]

[Elliott Hughes]

> · grep.[c1]:
>   neither the man-page nor the option `--help' list another available 
> option to
>   grep called `-X <matcher>' - more specifically `-X awk'
>   (even the info pages doesn't mention this option)

i think that's why it's a -X option: because it's undocumented 
functionality. like javac's -X stuff.

> · grep.c:
>   calling sequence:  egrep -P <expr> <file>
>   error message: conflicting matchers specified
>   -> after investigating grep.c I cannot see just one point for what 
> this error
>   message is good for, since there will be not one matcher-specific 
> setting done
>   before...

it's probably because of this:

`egrep' means `grep -E'.  `fgrep' means `grep -F'.

the fact that it's implemented using shell scripts rather than links 
means that "egrep -P" is treated by the implementation as "grep -E -P". 
it would probably be better if there was a -Xpersonality switch so we 
could communicate to grep that it was invoked as something else, so it 
could give a clearer diagnostic.

as it is, there's a bug in that code, as evidenced by the first 
parameter to the call to error. it's probably supposed to read like 
this instead:

Index: src/grep.c
===================================================================
RCS file: /cvsroot/grep/grep/src/grep.c,v
retrieving revision 1.81
diff -u -r1.81 grep.c
--- src/grep.c  18 Jan 2003 16:02:30 -0000      1.81
+++ src/grep.c  14 Nov 2004 19:00:20 -0000
@@ -1166,7 +1166,9 @@
 setmatcher (char const *m)
 {
   if (matcher && strcmp (matcher, m) != 0)
-    error (2, 0, _("conflicting matchers specified"));
+    {
+      error (2, 0, _("conflicting matchers specified: %s and %s"), 
matcher, m);
+    }
   matcher = m;
 }


strictly, i think it should read:

Index: src/grep.c
===================================================================
RCS file: /cvsroot/grep/grep/src/grep.c,v
retrieving revision 1.81
diff -u -r1.81 grep.c
--- src/grep.c  18 Jan 2003 16:02:30 -0000      1.81
+++ src/grep.c  14 Nov 2004 19:02:24 -0000
@@ -1166,7 +1166,10 @@
 setmatcher (char const *m)
 {
   if (matcher && strcmp (matcher, m) != 0)
-    error (2, 0, _("conflicting matchers specified"));
+    {
+      error (2, 0, _("conflicting matchers specified: %s and %s"), 
matcher, m);
+      return;
+    }
   matcher = m;
 }



> Have a nice day - and greetings from Germany.

gleichfalls.

--
http://www.jessies.org/~enh/

> CU Tom.
> (Thomas M.Ott)
> From: ThMO <address@hidden>
> Date: November 14, 2004 02:48:09 PST
> To: address@hidden
> Subject: [Fwd: grep v2.5.1]
>
>
> Hi folks,
>
> the attached mailwasn't delivered to the maintainer of grep v2.5.1, as 
> stated
> within the source code package's AUTHOR file.
> Please do forward it to this person.  THX
>
> CU Tom.
> From: ThMO <address@hidden>
> Date: November 14, 2004 02:08:58 PST
> To: address@hidden
> Subject: grep v2.5.1
>
>
> Hallo Bernhard,
>
> ich nutze die Gelegenheit, Dir in Deutsch zu schreiben.
> Ich hatte meinen grep von v2.0 auf v2.5.1 upgedatet und dabei Probleme:
>
> · ./configure --disable-nls:
>   1. Versuch: Linker bricht mit einem Fehler ab, da in libgreputils.a
>      die Funktion gettext() aufgerufen wird - nach Inspektion der 
> config.h
>      wird dort vermerkt, daß die Datei libintl.h präsent ist
>   => nur weil ich die Dateien libintl.[ha] installiert habe,  hat die 
> Option
>      --disable-nls Vorrang und die libintl.h darf nicht included werden
>   -> habe temporär die libintl.h aus dem include-path entfernt
>   2. Versuch: nach erneutem configure Lauf: Linker bricht mit dem 
> Fehler ab,
>      daß er die Funktion wcscoll() nicht einbinden kann
>   => diese Funktion kennt meine libc-5.4.46 nicht - auch wird diese in 
> der
>      wchar.h nicht aufgelistet
>   -> grundsätzlich wäre es, auch für andere GNU tools, durchaus 
> anzudenken,
>      ob nicht analog zu --disable-nls etwa eine Option 
> --disable-wide-char,
>      oder so ähnlich, eingeführt würde, denn schließlich müssen nicht 
> alle
>      so breite Zeichen verarbeiten, wobei es noch immer die 
> Möglichkeit gäbe,
>      sich der libiconv zu bedienen - so als Anmerkung
>   -> habe temporär die Dateien wchar.h und wctype.h aus dem 
> include-path ent=
>      fernt
>   3. Versuch: nach einem erneuten configure Lauf war alles O.K.
>      FYI mein System: Linux 2.0.35, gcc 2.7.2.1, libc 5.4.46,
>      binutils 2.9.1.0.4 und 2.14 (gas + objdump für MMX)
>   und bitte - frage mich nicht, ob ich mein System "upgraden" 
> möchte... THX
>
> · grep.1:
>   vor der Option `-P' fehlt eine Zeile mit der Anweisung `.TP', damit 
> diese
>   Option korrekt aufgelistet wird - desweiteren, da die Optionen 
> sortiert sind,
>   müßte sie nach unten verschoben werden
>
>   ja, ich weiß, daß die GNU Leute ihre info Dateien bevorzugen - ich 
> persönlich
>   präferiere die man-pages und sehe mir die info's dann an, wenn ich 
> einen etwas
>   tiefergehenden Einblick wünsche, wobei info Dateien auch einen 
> Nachteil haben:
>   -> apropos und whatis
>
> · grep.[c1]:
>   weder die man-page noch die Option --help listen die Option `-X 
> <matcher>',
>   in diesem Kontext hauptsächlich ``-X awk'', auf
>   (auch die info Datei benennt diese Option nicht)
>
> · grep.c:
>   es wird grundsätzlich die Funktion `set_matcher()' verwendet, bis 
> auf ein ein=
>   ziges Mal - und zwar nach dem Verarbeiten der Optionen, was wohl 
> inkonsequent
>   ist...
>
> · grep.c:
>   folgender Aufruf:  egrep -P <expr> <file>
>   Fehlermeldung: conflicting matchers specified
>   -> nach Inspektion dieser Datei stellt sich mir die Frage, was diese 
> Fehler=
>      meldung soll ?
>   es wird *nichts* matcher-spezifisches aufgesetzt, sodaß die 
> Sinnhaftigkeit
>   dieser Fehlermeldung in Frage gestellt werden darf...
>   -> man könnte gleich die gesamte Funktion set_matcher() eliminieren
>
> · grep.c:
>   * start of extract out of main() *
>   1 program_name = argv[0];
>   2 if (program_name && strrchr (program_name, '/'))
>   3   program_name = strrchr (program_name, '/') + 1;
>   * end of extract *
>
>   Zeile 1+2: unter Unix Systemen kann `program_name' gar nicht NULL 
> sein - dies
>   passiert höchstens unter Windoof Systemen, (zu diesem Punkt werde 
> ich einige
>   Zeilen weiter unten noch meine Senf dazugeben) sodaß dieser sinnlose 
> Vergleich
>   per #ifdef auskommentiert werden kann
>
>   Zeile 2+3: die Funktion strrchr() wird 2× aufgerufen - auch wenn 
> sich das auf
>   heutigen Kisten im GHz Bereich nicht sonderlich auswirkt, (wiewohl 
> nicht jeder
>   eine so schnelle Kiste hat) ist das eine Verschwendung von Resourcen
>
>   Ich habe so in letzter Zeit den Eindruck, daß GNU Software schon 
> lange nimmer
>   das ist, was sie mal war - obiges hätte ich vor Jahren wohl niemals 
> sehen dürfen.
>   Auch scheint es so auszusehen - und bitte, das ist keine Kritik an 
> Dir persönlich,
>   sondern schon etwas allgemeiner - als ob für die GNU Jungs die 
> Unterstützung von
>   Maso$oft oberste Priorität hätte - ich erinnere mich an einen 
> Vortrag von RMS,
>   als er gegen M$ wetterte, muß heute jedoch erkennen dürfen, daß 
> meine ältere
>   Linux-Kiste als obsolet abgestempelt wird, während M$, in großen 
> Teilen jeg=
>   liche Standards verletzend, unterstützt wird.  Das ist sehr 
> verwunderlich...
>
> BTW, ich begrüße es, daß diese Version wieder - im Gegensatz zur 
> v2.4.2 - den
> Namen des Kommandos inspiziert, um dessen Funktion zu bestimmen, auch 
> wenn POSIX
> das mal wieder anders sieht - wobei manche POSIX Regelungen durchaus 
> in Frage zu
> stellen sind, was wohl auch daran liegen dürfte, daß M$ dort gewichtig 
> vertreten
> ist...
>
> Die Option `--color' ist eine nette Spielerei - erspart mir in manchen 
> Situationen
> die Sequenz `egrep ... | less', wobei ich im `less' nochmals 
> dieselbige RE an=
> setze, damit die betreffenden Stellen hervorgehoben werden.
>
> Das soll's gewesen sein - wünsche Dir noch'n schönen Tag.
>
> Salút  Tom.
> (Thomas M.Ott)