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

[ThMO]

Hello Julian and others listening,

> I'm sorry that you are having problems with Grep.  Bernhard ("Bero") is no
> longer the maintainer; Stepan Kasal has taken over that job.  In any case,
> please address your questions to the whole community of Grep developers on the
> mailing list <address@hidden>, not just to one person.
> 
> If you can re-write your request in English and send it to that list, I'm sure
> someone will be able to help you.

while upgrading gnu grep from v2.0 to v2.5.1, I had the following problems:

· ./configure --disable-nls:
  1. try: linking failed with an error saying that some function within
     libgreputils.a is calling gettext() - after looking at config.h I noticed
     that HAVE_LIBINTL_H has been set
  => even though I do have installed libintl.[ha] specifying the configure 
option
     --disable-nls has to take precedence over my installed libintl stuff...
  -> moved temporarily libintl.h out of the include-path

  2. try: after re-configuring: linking failed with an error saying that the
     function wcscoll() could not be linked
  => that's correct, since my older Linux libc-5.4.46 doesn't know anything 
about
     this function - it even isn't listed within wchar.h
  -> generally speaking - it might be worthwhile thinking about another option,
     just like --disable-nls, which may be called --disable-wide-char, or 
something
     like that, as not everyone needs to process wide characters for their dayly
     work...  this might be interesting for other gnu tools too, since at 
present
     they work on 8-bit characters already and therefore only those, really feel
     the need for wider chars, could specify this option...
  -> moved additionally wchar.h and wctype.h out of the include-path

  3. try: again after re-configuring all went well
     FYI my 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 for MMX support)
  and please, don't ask me to "upgrade" my working system... THX

· grep.1:
  the option `-P' is missing a `.TP' command one line before, in order to be
  formatted correctly - as the options are sorted, this option needs to be moved
  some lines below

· 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)

· 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...

· 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 *

  line 1+2: for unix systems `program_name' could never be NULL - this could 
only
  happen to M$ windog system, so this test could be #ifdef'd out

  line 2+3: the function strrchr() will be called twice - unneccessarily

  some words I like to say not just to grep, but to other gnu tools too:
  it looks like it seems to be a primary goal to gnu people to support M$ 
systems,
  which reminds me immediately listening to RMS at a hearing some day talking
  against M$ - but nowadays my (still) older libc-5 based Linux system has been
  called obsolete (read from the latest gdb release), while M$, ignoring and 
fight=
  ing again most so-called standards, will be supported even more, which makes 
me
  really wondering...

BTW, I'm happy to see that this version again looks at its name in order to 
setup
the appropriate matcher routine, even though POSIX still says something 
different,
but then some POSIX rules are really questionable...

The `--color' option is a nice thing - as it saves me a lot re-typing under some
circumstances, where I used to `egrep ... | less' re-typing the RE inside less
again in order to see the relevant pieces within a line highlighted.

Have a nice day - and greetings from Germany.

CU Tom.
(Thomas M.Ott)
> --- Begin Message ---
>
>
>
> Subject: 
>
> [Fwd: grep v2.5.1]
>
>
>
>
> Date: 
>
> Sun, 14 Nov 2004 11:48:09 +0100
>
>
>
>
> 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.
> > --- Begin Message ---
> >
> >
> >
> > Subject: 
> >
> > grep v2.5.1
> >
> >
> >
> >
> > Date: 
> >
> > Sun, 14 Nov 2004 11:08:58 +0100
> >
> >
> >
> >
> > 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)
> >
> > --- End Message ---
>
> --- End Message ---