On Wed, Aug 27, 2008 at 12:54 AM, Kyle Wheeler <[EMAIL PROTECTED]> wrote: > On Tuesday, August 26 at 11:46 PM, quoth Shreevatsa R: >>> Skip the escaping, and just use quotes: >>> >>> mutt -e "push '<limit>~i "$MID"<Enter><group-reply>'" $@ >>> >>> AFAIK quote characters aren't allowed in Message-IDs. >> >> That's probably true, but quotes don't work. Start mutt and do >> <limit>~i "<[EMAIL PROTECTED]>" and it *won't* match Message-ID: <[EMAIL >> PROTECTED]>". Neither >> will ~i '<[EMAIL PROTECTED]>' nor ~i "<[EMAIL PROTECTED]>"; the only things >> that work are ~i >> '<[EMAIL PROTECTED]>' or ~i <[EMAIL PROTECTED]> or ~i "<[EMAIL PROTECTED]>" >> (but not ~i '<[EMAIL PROTECTED]>'). >> I would consider this behaviour a bug in mutt, probably some would >> not, so I didn't mention it the last time. Is there a reason things >> are this way? (A design reason, not "that's how it happens to be >> implemented".) > > Well, part of the problem is your shell, which eats some of the quotes > (and can potentially eat the $) before mutt ever sees them.
Yes, this is the easiest part of the puzzle, and also easiest to fix :) [Given that the shell is familiar, can provide arbitrary feedback, etc.] This is also why I phrased everything in my previous email as "from within mutt"; to avoid shell complications and focus on the mutt ones. > The other thing to keep in mind is that the ~i simple pattern takes a > regular expression as an argument, rather than a simple string. Yes, but it *could* have been made to understand text within " " (or within ' ', or anything, really) as a string that must be interpreted literally. > Anyway, there's an additional problem, > which is that there's an extra set of de-quoting (and de-escaping) > that goes on, which is in interpreting the argument to ~i. The reason Yes, this is the other problem. > for this is to distinguish between a compound match that matches > message ID and potentially something else (e.g. ~i foo ~s subj) and a > long and strange matching string (e.g. ~i "foo ~s subj" or even ~i > foo\ ~s\ subj). I don't buy this. Mutt could easily have a system to distinguish between such cases (see below), it just happens not to. > Mutt sees: > push "<limit>~i <a\\$b><enter>" > Mutt's pattern parser sees: > ~i <a\$b> > Mutt's regex engine sees: > <a$b> (remember: $ != [$]) The latter step is poor design. There is no reason that mutt cannot be made to remember its strings; it is parsing too often. Mutt should handle its strings itself without making the user have to spend the effort. > Does that make sense? Everything "makes sense" in that it is understandable what is happening. (And thank you for explaining, I understand it better now than I thought I did before.) It is not sufficient justification for being that way, however. Why can't the regex engine see the same strings that the pattern parser sees? Why is mutt parsing so often? The only "parsing" that the pattern parser needs to do is break up the user-input string into "logical parts" of the form (~i EXPR), (~s EXPR), etc., and then each corresponding part can do its job with the actual string that was input. (The parser might also have to do some logical AND/OR/NOT operations, but that's later.) It has no reason to poke at the actual EXPR strings and mess with them. The parser already has a () logical grouping operator; I maintain that this is all it needs. By simply refusing to interpret ~i foo\ and\ bar as one argument to ~i and instead requiring either ~i "foo and bar" or ~i (foo and bar), it can completely do away with the extra dequoting step and pass to the regex engine the same strings it gets, intact. It spends an extra step parsing the string and dequoting all characters, when all it needs to do is something much simpler. Anyway, nevermind this rant; back to the original question: Given that mutt has no syntax for specifying that a string must be interpreted literally (an annoying omission), "escaping" is necessary. Simply replacing each $ with \\$ (or with [$]) works for everything I have encountered, so the question is entirely hypothetical: what more might I have to worry about, and has anyone thought about the problem of escaping a string for mutt and solved it? There is no consistency to speak of among regular expression implementations; each has its own quirks; and simply using another language's "escape" function might not work with mutt. -S
