<<< Date Index >>>     <<< Thread Index >>>

Re: Replying to a specific message



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 "<a$b@c>" and it *won't* match Message-ID: <a$b@c>". Neither 
> will ~i '<a$b@c>' nor ~i "<a\$b@c>"; the only things that work are ~i 
> '<a\$b@c>' or ~i <a\\$b@c> or ~i "<a\\$b@c>" (but not ~i '<a\\$b@c>'). 
> 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.

For example, in bash, this:

     mutt -e "push '<limit>~i "$MID"<enter><group-reply>'"

... gets interpreted by the shell as five components, three of which 
are concatenated:

     1. mutt
     2. -e
     3. push '<limit>~i
     4. $MID
     5. <enter><group-reply>'

And because of that, the shell will expand $MID for you AND mutt will 
not see the quotes around it. For example, f the value of MID was 
"foo", mutt would receive two arguments (note that there are very few 
quotes in the second argument, because they were removed by your 
shell):

     1. -e
     2. push '<limit>~i foo<enter><group-reply'

So some of the escapes are necessary to get the string past your 
shell. Thus, you can't guarantee that the command you enter into a 
running mutt will have the exact same escapes in it as the command you 
need to have when you are specifying arguments to mutt.

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. And 
because it's a regular expression, the $ has a special meaning (yeah, 
I know, annoying). In order to tell the regular expression engine that 
$ should NOT have a special meaning, you have to either escape the $ 
or you have to put it in square brackets, and that escape has to 
survive the dequoting of the shell. To top it all off, as you're 
no-doubt aware, double quotes (") have a different meaning in most 
shells from single quotes (') - double quotes (often) understand 
escapes, while single quotes generally don't (and take everything 
within them literally), so "\$" often translates to a single $, while 
'\$' often translates to \$. But exactly which is true depends on the 
shell and the application. 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 
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).

Here's an example:

1. You type:
       mutt -e 'push "<limit>~i $MID<enter>"'
    Mutt sees:
       push "<limit>~i $MID<enter>"
    Mutt's pattern parser sees:
       ~i $MID
    Mutt's regex engine sees:
       $MID

2. You type:
       mutt -e "push '<limit>~i $MID<enter>'"
    Mutt sees:
       push '<limit>~i foo<enter>'
    Mutt's pattern parser sees:
       ~i foo
    Mutt's regex engine sees:
       foo

3. You type:
       mutt -e "push '<limit>~i <a$b><enter>'"
    Mutt sees:
       push '<limit>~i <afoo><enter>'
    Mutt's pattern parser sees:
       ~i <afoo>
    Mutt's regex engine sees:
       <afoo>

4. You type:
       mutt -e "push '<limit>~i <a\$b><enter>'"
    Mutt sees:
       push '<limit>~i <a$b><enter>'
    Mutt's pattern parser sees:
       ~i <a$b>
    Mutt's regex engine sees:
       <a$b>

5. You type:
       mutt -e "push '<limit>~i <a\\$b><enter>'"
    Mutt sees:
       push '<limit>~i <a\foo><enter>'
    Mutt's pattern parser sees:
       ~i <a\foo>
    Mutt's regex engine sees:
       <afoo>

6. You type:
       mutt -e 'push "<limit>~i <a\\$b><enter>"'
    Mutt sees:
       push "<limit>~i <a\\$b><enter>"
    Mutt's pattern parser sees:
       ~i <a\$b>
    Mutt's regex engine sees:
       <a$b>      (remember: $ != [$])

7. You type:
       mutt -e 'push "<limit>~i <a\\\$b><enter>"'
    Mutt sees:
       push "<limit>~i <a\\\$b><enter>"
    Mutt's pattern parser sees:
       ~i <a\\$b>
    Mutt's regex engine sees:
       <a\$b>      (remember: \$ == [$])

8. You type:
       mutt -e "push '<limit>~i <a\\\$b><enter>'"
    Mutt sees:
       push "<limit>~i <a\$b><enter>"
    Mutt's pattern parser sees:
       ~i <a$b>
    Mutt's regex engine sees:
       <a$b>      (remember: \$ == [$])

Does that make sense?

All this confusion, when it boils down to the nitty-gritty, is 
actually in the name of consistency: so that each type of quote 
behaves as it would in most standard shells, and each level of 
dequoting behaves predictably. The confusion generally stems from just 
how shockingly many levels of interpretation a command can pass 
through before getting evaluated.

~Kyle
- -- 
Of course it's the same old story. Truth usually is the same old 
story.
                                                   -- Margaret Thatcher
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iEYEARECAAYFAki03fsACgkQBkIOoMqOI17dIQCfSFmSbqVHZPwIVk5Wylzwbu5d
o0AAn1Yq1q+KkbqXyRb/T0sbsH8YB5P0
=c75H
-----END PGP SIGNATURE-----