Update to 2.15:

* Noteworthy changes in release 2.15 (2013-10-26) [stable]

** Bug fixes

  grep's \s and \S failed to work with multi-byte white space characters.
  For example, \s would fail to match a non-breaking space, and this
  would print nothing: printf '\xc2\xa0' | LC_ALL=en_US.UTF-8 grep '\s'
  A related bug is that \S would mistakenly match an invalid multibyte
  character.  For example, the following would match:
    printf '\x82\n' | LC_ALL=en_US.UTF-8 grep '^\S$'
  [bug present since grep-2.6]

  grep -i would segfault on systems using UTF-16-based wchar_t (Cygwin)
  when converting an input string containing certain 4-byte UTF-8
  sequences to lower case.  The conversions to wchar_t and back to
  a UTF-8 multibyte string did not take surrogate pairs into account.
  [bug present since at least grep-2.6, though the segfault is new with 2.13]

  grep -E would segfault when given a regexp like '([^.]*[M]){1,2}'
  for any multibyte character M. [bug introduced in grep-2.6, which would
  segfault, but 2.7 and 2.8 had no problem, and 2.9 through 2.14 would
  hit a failed assertion. ]

  grep -F would get stuck in an infinite loop when given a search string
  that is an invalid byte sequence in the current locale and that matches
  the bytes of the input twice on a line.  Now grep fails with exit status 1.

  grep -P could misbehave.  While multi-byte mode is only supported by PCRE
  with UTF-8 locales, grep did not activate it.  This would cause failures
  to match multibyte characters against some regular expressions, especially
  those including the '.' or '\p' metacharacters.

** New features

  grep -P can now use a just-in-time compiler to greatly speed up matches,
  This feature is transparent to the user; no flag is required to enable
  it.  It is only available if the corresponding support in the PCRE
  library is detected when grep is compiled.

0 files changed, 0 insertions, 0 deletions