Re: possible grep bug: -i switch with character class

[Bob Proulx]

Chris Jerdonek wrote:
> I had trouble compiling directly from source by following the INSTALL
> file.

That is a generic INSTALL file that covers building packages that use
the autotools.  Instead of every package having different installation
procedures it is easier if packages all share the same procedure and
then modify themselves to fit.

> For example, I got the following error when running "make":
> search.c:44:19: error: pcre.h: No such file or directory

Well, you will need to install any dependent libraries needed by the
package.  In my case that would be installing that library on the
system with "apt-get install libpcre-dev" but I have no idea on the
Mac.  You can manually configure the package not to use the pcre (perl
compatible regular expressions).  Since I have always had the pcre
library installed I had never run into the case of trying to compile
without it.  It always just built easily for me and that was why I
suggested it.

A cursory glance through the configure.ac for grep leads me to believe
that it will try to detect if you do not have libpcre available and in
that case automatically disable building with that library.  If that
isn't working then that is certainly a valid problem to report
upstream.  It is something that perhaps isn't tested very well since
that is a library that will most likely always be installed.  So it
might actually be broken without it and no one would realize it.

> What I did instead was get the latest version v2.5.4 using MacPorts (
> http://www.macports.org/ ), which seems to have supplanted
> DarwinPorts.

Good to know.

> I'm not seeing the issue in v2.5.4 even with the UTF8 locale, which is
> good.  You can see more info I posted in a follow-up to my bug report.

Thanks for following up on the report with the subsequent information.

> > Also posting to bug-gnu-utils for grep is okay.  It is a generic
> > catchall for all things gnu.  You will have people like me here
> > helping.  But for grep there is a specific mailing list just for grep
> > bugs.  For more follow-up you would reach the grep maintainers
> > directly at address@hidden instead of here.  That is the bug
> > reporting address listed in the grep --help output.
> 
> I apologize for posting here instead of to the greps bug list.  The
> man page listed this e-mail address (though the man page dates to
> 2002).  I did learn a lot from you though, so I appreciate all your
> help.

It is all good so no worries.  Things had just progressed to the limit
of what I could do to help and so it was time to direct things to the
better group for it.  I am glad I was able to provide some useful help.

> All of this makes me wonder how Apple decides what version of software
> to include in its Mac OS X versions.  Let me know if you have any
> insight!

I have no idea about Apple in particular.  But there are a lot of
software distributions using ports of GNU Project code.  Obviously the
emphasis for the GNU Project is to help GNU but when possible it is
good to try to help others too.  It exposes a wider audience to Free
Software and perhaps will win some more advocates for it.  But GNU is
currently a collection of many different projects.  Each operates in
the way that their respective maintainers want them to operate.  Some
do things one way and some another way.  Most importantly each one
releases on their own independent schedule.  It is like having ten
thousand independent conveyer belts each running at a different speed
and each producing packages at a different rate.  This isn't too much
of a problem for source based GNU systems since GNU is all about the
source.  For a large number of users this is the best model for them
to use.  This has been called the software bazaar model.

But the software distributions have a problem to manage this type of
bazaar.  They will need to release a complete bundle of software all
together.  They need to turn the bazaar model into the cathedral
model.  This meets a different set of user's needs.  Usually this
means picking the latest stable known good version of a package and
including it in a distribution.  This goes through a time of testing
that may be months and months.  During the time of testing a new
version of any particular package may be released.  Do you throw away
all of the previous testing, update to it, and start the clock ticking
again?  Obviously you would never release a full distribution if you
did that and therefore software distributions always release with at
least some software that has already been replaced upstream with a
newer version.

Many upstream projects only want to discuss problems in their current
top of trunk source code.  You can see why.  It can take a lot of
energy to track older versions.  And who knows what versions the many
hundreds of software distributions are shipping at any given time.  An
upstream can't track everyone.  Personally I have more sympathy for
people using recent known good stable releases even if they have been
superseded by newer upstream releases.  But unfortunately some others
are somewhat contemptuous of anything but today's source code.  The
end user has a hard time knowing the difference.

A good plan for end users who are wishing to report bugs is to report
them to their software distribution vendor.  The maintainer there will
know the upstream processes.  They can test the bug against the latest
upstream code and deduce if the bug still exists.  They can tell if
the bug is something they did in the distribution.  So reporting to
the distributor is never wrong.  You can report it upstream too.  You
just personally went through this and hopefully it wasn't too
unpleasant.  :-) But it looks like it in your case it is something
that has already been addressed and will hopefully trickle down to
your system in the future.  It just takes some time.  In which case
poking your vendor may encourage them to trickle it down sooner.

More agressive users will get the latest current stable and compile it
themselves.  You just did that.  If the problem still exists then they
will report that upstream.  That is great!  It is all about the source
after all.  But that is also more work for the end user who may not be
as skilled for it.  However learning more about how things work is
never bad either and with the knowledge gained everyone wins.  And
often during this test the upstream compile works fine.  In which case
they have another item they could report to their vendor.  Or the
problem could be worse there because of a turn in direction that
upstream has taken.  In which case that clearly needs to be reported.
Many eyes make all bugs transparent.

Also the vendor may have had to make a compromise.  You might be
running into something that is causing you a problem but is necessary
in order to prevent a different worse problem.  The Cygwin project is
a good example because the underlying system is so very limited that
many compromises must be made.

Well that is enough of reading me talk about the current practice of
software distribution.  I am glad you were able to make progress on
your problem.  I look forward to reading any future reports you make.

Good luck!
Bob