lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LSR inconsistencies


From: Sebastiano Vigna
Subject: Re: LSR inconsistencies
Date: Mon, 25 Apr 2022 18:48:14 +0200

Il giorno sab 12 ott 2019 alle ore 12:08 Werner LEMBERG <wl@gnu.org> ha
scritto:

> >
> >   https://lsr.di.unimi.it/list.php?type=snippet
> >
> > enter in the Title-box:
> >
> >   Template: integrating \startTextSpan and \stopTextSpan in a customized
> TextSpanner
> >
> > then click "Enable filter".  Nothing returns.
>

The problem lies in the quite quirky escape rules for LIKE:

"MySQL uses C escape syntax in strings (for example, \n to represent the
newline character). If you want a LIKE
<https://dev.mysql.com/doc/refman/8.0/en/string-comparison-functions.html#operator_like>
string
to contain a literal \, you must double it. (Unless the NO_BACKSLASH_ESCAPES
<https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sqlmode_no_backslash_escapes>
SQL
mode is enabled, in which case no escape character is used.) For example,
to search for \n, specify it as \\n. To search for \, specify it as \\\\;
this is because the backslashes are stripped once by the parser and again
when the pattern match is made, leaving a single backslash to be matched
against."

My comments claim that I knew them:

     /* Escapes in LIKE arguments are a bit complicated, as the backslash
      escapes BOTH the string literal AND the pattern. Apparently, at least
with
      MySQL, this escaping is still not sufficient, and AddSlashes should
      be preceded by substitution of "\" with "\\". */

However, the quote substitution was not there (for some reason I don't
remember; this code was written 19 years ago).

This has been fixed.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]