[bug #25805] fgrep or "grep -F" fails to match patterns on Windows/DOS

[Harold Bamford]

URL:
  <http://savannah.gnu.org/bugs/?25805>

                 Summary: fgrep or "grep -F"  fails to match patterns on
Windows/DOS
                 Project: grep
            Submitted by: hbamford
            Submitted on: Tue 10 Mar 2009 12:57:06 AM GMT
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

On a Windows/DOS box, the newline is actually \r\n rather than the normal
Unix \n. The function Fcompile() (in src/search.c around line 500) doesn't
account for this and so the \r is treated as part of the pattern. This is
almost never what was intended. I checked the latest version, 2.5.4

As a temporary kludgey patch, I have this alternate version of that
function:


COMPILE_FCT(Fcompile)
{
  char const *beg, *lim, *err;

  kwsinit ();
  beg = pattern;
  do
  {
    for (lim = beg; lim < pattern + size && *lim != '\n'; ++lim)
      ;

#if HAVE_DOS_FILE_CONTENTS      /* heb */
   
//-----------------------------------------------------------------------------------
    // Try to handle Windows/DOS \r\n pairs as just a \n.
    //
    // This function (Fcompile) is called as:
    //
    //          compile(keys, keycc);
    //
    // which becomes:
    //
    //          Fcompile(pattern,size);
    //
    // if the -F option was given or if the program is called 'fgrep' rather
than 'grep'.
    // This means that the patterns are in a file, seperated by newlines. And
that is
    // the problem; newlines are different on different machines (like
Windows and Mac).
    // This "fix" only addresses the case of Windows/DOS machines using ASCII
pattern
    // files.
    //
    // This is a ghastly kludge, but for straight ASCII input on a Windows
machine
    // it seems to work.  The idea is that if we have just encountered a '\n'
char
    // (as the above for() loop has terminated), then see if it was preceded
by a '\r'
    // char. If so, tell kwsincr() that the string is shorter by 1 than
actually found.
    //
    // This won't work for multibyte chars and it probably doesn't handle
lots of other
    // cases, but it lets me get by on my Windows box running Cygwin.
   
//-----------------------------------------------------------------------------------
    if(((lim - beg) >= 1) &&    /* must have at least 2 chars to look at */
        (*lim == '\n')    &&    /* last one is a normal Unix-style newline char
*/
        (*(lim - 1) == '\r'))   /* next-to-last one is a carriage-return char
*/
    {
      // Indicate string is shorter by 1
      if ((err = kwsincr (kwset, beg, (lim - beg) - 1)) != 0)
        error (2, 0, err);
    }
    else
    {
      // Normal, non-Windows operation
      if ((err = kwsincr (kwset, beg, lim - beg)) != 0)
        error (2, 0, err);
    }
#else
    // This does not handle Windows/DOS newlines (\r\n instead of \n)
    if ((err = kwsincr (kwset, beg, lim - beg)) != 0)
      error (2, 0, err);
#endif

    if (lim < pattern + size)
      ++lim;
    beg = lim;
  }
  while (beg < pattern + size);

  if ((err = kwsprep (kwset)) != 0)
    error (2, 0, err);
}






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?25805>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/