Re: Exclusive matching
Andrew W. Nosenko [EMAIL PROTECTED] wrote on Tue, 30 May 2000: Right answer is: ^(~L alice)|(~L bob)|(~L carol) Doesn't this mean that the ^ operator is only applied to the first of the patterns, not the 2 that follow? I guess it's a question of precedence, but I would've expected it to work that way (| coming before ^ in the precedence order). Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Ten years since I went out of my mind; I won't go back.
Re: Exclusive matching
On Sun, May 28, 2000 at 10:33:52PM -0400, David T-G wrote: % Ah, I see. It's ^~L "(alice|bob|carol)". Precedence would be a good % topic for the manual to go over quickly. I think most Unix users (after struggling with bash, grep, etc.) develop a feeling on where and how and what to quote. Whoops. Pardon me for jumping in here, but shouldn't any parser be able to detect a ( and put everything up until the matching ) in a separate precedence? It's not so simple as it sounds. There are many quoting issues, like \( or [abc)def], that are not exactly matching parentheses. I still don't see why the parser would break the expression into three ORs with an ( in one and a ) in another unless the code is just plain broken -- but I can't read C enough to have any idea :-) Note that that's not a flame of the code or developers, especially since I'm in no position to provide a patch to "fix" the behavior... The code is indeed broken. Try, for example, this pattern: (~b "default[)]") Mutt just scans for the first matching `)' ignoring any quotes, escapes, etc. OK, I've got to go. Expect a patch in the evening. Marius Gedminas -- "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" (Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi)
Re: Exclusive matching
Marius, et al -- ...and then Marius Gedminas said... % On Sun, May 28, 2000 at 10:33:52PM -0400, David T-G wrote: % % Ah, I see. It's ^~L "(alice|bob|carol)". Precedence would be a good % % topic for the manual to go over quickly. % % I think most Unix users (after struggling with bash, grep, etc.) develop % a feeling on where and how and what to quote. Probably right, but it wouldn't hurt to mention quotes as well -- or, more likely, point folks off to an already-written regexp reference, like the one that no doubt comes with the rx package. I think the trick above, though, was knowing *where* to put the quotes (leaving the ~L on the outside). And, of course, that sort of instruction isn't easily condensed down to one paragraph in the manual. % % Whoops. Pardon me for jumping in here, but shouldn't any parser be able % to detect a ( and put everything up until the matching ) in a separate % precedence? % % It's not so simple as it sounds. There are many quoting issues, like \( % or [abc)def], that are not exactly matching parentheses. Well, that's why I specifically said "matching" instead of "next" :-) I remember having to write a regexp parser in school; we took each advance, starting from the very basic with no nesting, one week (yes, an entire week, and we needed it then) at a time -- and we never even had to deal with classes like [abc]. But, hey, elegance is the art of making the not-simple look simple :-) % % into three ORs with an ( in one and a ) in another unless the code is % just plain broken -- but I can't read C enough to have any idea :-) Note % % The code is indeed broken. Try, for example, this pattern: % % (~b "default[)]") % % Mutt just scans for the first matching `)' ignoring any quotes, escapes, % etc. Yep. % % OK, I've got to go. Expect a patch in the evening. Thanks a bunch, in advance! % % Marius Gedminas % -- % "Only wimps use tape backup: _real_ men just upload their important stuff % on ftp, and let the rest of the world mirror it ;)" % (Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi) :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: Exclusive matching
Mikko Hanninen wrote: : I didn't look into this deeply, but just to throw an idea out -- : did you try something like: : : ^~L (alice|bob|carol) Right answer is: ^(~L alice)|(~L bob)|(~L carol) -- Andrew W. Nosenko([EMAIL PROTECTED])
Re: Exclusive matching
Hi, folks -- ...and then David Champion said... % % Well, it does, but it parses from "top down" -- it takes the whole % string first, and then splits it up to expressions. | can be "or", % so it splits it at that. It doesn't look at the context. % % You can avoid it by quoting it, like you did, or by giving the pattern % in quotes: "^~L (alice|bob|carol)" (or something like that). % % Ah, I see. It's ^~L "(alice|bob|carol)". Precedence would be a good % topic for the manual to go over quickly. Whoops. Pardon me for jumping in here, but shouldn't any parser be able to detect a ( and put everything up until the matching ) in a separate precedence? I still don't see why the parser would break the expression into three ORs with an ( in one and a ) in another unless the code is just plain broken -- but I can't read C enough to have any idea :-) Note that that's not a flame of the code or developers, especially since I'm in no position to provide a patch to "fix" the behavior... :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: Exclusive matching
David Champion [EMAIL PROTECTED] wrote on Thu, 25 May 2000: OK. I didn't need to escape the parens at all, just the pipes. This expression is exactly what I'm looking for: ~L alice ~L bob ~L carol ^~L (alice\|bob\|carol) I'm curious, do you really need the first part, the three matches? The last part should do their job too. Since you tried these things, I suppose you tested it without them too... (I was hoping that the parser would change the meaning of '|' inside parens -- I didn't think of "\|" because I wasn't looking for a literal pipe.) Well, it does, but it parses from "top down" -- it takes the whole string first, and then splits it up to expressions. | can be "or", so it splits it at that. It doesn't look at the context. You can avoid it by quoting it, like you did, or by giving the pattern in quotes: "^~L (alice|bob|carol)" (or something like that). Now, suppose I'm Alice. I'd like to be able to remove the "alice" parts of that and let $alternates cover it, but I don't see any way to do that. Is there some way to get $alternates into the expression? I don't think there's any way to expands a random Mutt variable in these situations, only the %-expandos... Should there be? I'm happy with a "yes" to either question. :) That's a "no" and a "maybe"... Sorry, no "yes". :-) Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / It *is* as bad as you think, and they *are* out to get you.
Re: Exclusive matching
On 2000.05.25, in [EMAIL PROTECTED], "Mikko Hänninen" [EMAIL PROTECTED] wrote: ~L alice ~L bob ~L carol ^~L (alice\|bob\|carol) I'm curious, do you really need the first part, the three matches? The last part should do their job too. Since you tried these things, I suppose you tested it without them too... Yes, I do. The second part does't guarantee that a message is to/from all three. The first three patterns (ANDed) make sure that all three people get the message, and the last pattern makes sure that ONLY those three get it. Without it, a message from Alice to Bob (excluding Carol) is still matched. Well, it does, but it parses from "top down" -- it takes the whole string first, and then splits it up to expressions. | can be "or", so it splits it at that. It doesn't look at the context. You can avoid it by quoting it, like you did, or by giving the pattern in quotes: "^~L (alice|bob|carol)" (or something like that). Ah, I see. It's ^~L "(alice|bob|carol)". Precedence would be a good topic for the manual to go over quickly. do that. Is there some way to get $alternates into the expression? I don't think there's any way to expands a random Mutt variable in these situations, only the %-expandos... That's what I think, too, for the present. Should there be? I'm happy with a "yes" to either question. :) That's a "no" and a "maybe"... Sorry, no "yes". :-) "Wait and see" -- you are wise. Well, here's an example of wanting to evaluate your own address, where ~P and ~p are not enough. I'm not sure what an appropriate solution would be, except for permitting expansion of any "set" variable in the editor, but I can understand reluctance to do that. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Exclusive matching
Alice, Bob, and Carol want to find all email that was sent from any one
of them to BOTH of the others, but that was not sent to ANY fourth
person.
I can make mutt match all messages that include Alice, Bob, and Carol:
~L alice ~L bob ~L carol
My mailbox has a message from Carol to Alice, excluding Bob, which this
pattern does not match. Fine.
But I need still to exclude messages which are cc:ed to any fourth
party. The Mutt manual says:
4.2.1. Pattern Modifier
Note that patterns matching 'lists' of addresses (notably c,C,p,P and
t) match if there is at least one match in the whole list. If you want
to make sure that all elements of that list match, you need to prefix
your pattern with ^. This example matches all mails which only has
recipients from Germany.
If I read that correctly, then this pattern:
^ ~L alice | ~L bob | ~L carol
should exclude messages to Dave. It doesn't -- it matches everything.
A look at the source code suggests that this is a misread, though, and
that "^" goes before any pattern component. Well, this pattern:
^~L alice | ^~L bob | ^~L carol
doesn't match anything at all.
I expect by combining these two, I get what I want:
~L alice ~L bob ~L carol (^~L alice | ^~L bob | ^~L carol)
But that doesn't work.
I briefly tried using parens in a regexp way -- e.g.,
~L (alice|bob|carol)
but that doesn't seem to work at all. And when I try escaping the
parens just to see what happens, I get "Unmatched ( or \(".
I'm not sure whether I have a bug, an intractable problem, or a clue
deficiency. Any tips? What's the right way to approach this? Mailing
lists/aliases are not really a solution for this particular problem.
Thanks. Here's my mutt -v. I attached a mailbox that contains 8
messages: 6 that I want matched, 1 that is from Carol to Alice, Bob,
and Dave, and 1 that does not include Bob. (The last two should not be
matched.) Ignore the "patches applied" part. :)
Mutt 1.3i (2000-05-09)
Copyright (C) 1996-2000 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: SunOS 5.8 [using slang 10309]
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL -USE_SETGID +USE_DOTLOCK +USE_FCNTL -USE_FLOCK
+USE_IMAP +USE_GSS +USE_SSL +USE_POP -HAVE_REGCOMP +USE_GNU_REGEX
+HAVE_COLOR +HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS +ENABLE_NLS
SENDMAIL="/usr/lib/sendmail"
MAILPATH="/var/mail"
SHAREDIR="/opt/pkgs/mutt-1.3/lib/mutt"
SYSCONFDIR="/opt/pkgs/mutt-1.3/etc"
ISPELL="/opt/bin/ispell"
Patches applied:
Patch Name: mutt-1.1.12.dgc.krb5.2
+ URI: http://home.uchicago.edu/~dgc/mutt
+ Desc: Fix Kerberos 5 checking for pre-1.1 MIT in configure.in
Patch Name: mutt-1.1.12.skimo.exmhthread.1
+ Desc: Modify threading for exmh's (and others'?) oddball In-Reply-To:
Patch Name: mutt-1.3.dgc.xlabel.3
+ URI: http://home.uchicago.edu/~dgc/mutt
+ Desc: Add in-line status-bar editor for X-Label: header
Patch Name: patch-1.1.14.waf.compose_status.1
+ Desc: Add summary format for Compose menu
To contact the developers, please mail to [EMAIL PROTECTED].
To report a bug, please use the muttbug utility.
Re: Exclusive matching
On 2000.05.24, in [EMAIL PROTECTED], "David Champion" [EMAIL PROTECTED] wrote: I attached a mailbox that contains 8 messages: 6 that I want matched, 1 that is from Carol to Alice, Bob, and Dave, and 1 that does not include Bob. (The last two should not be matched.) Oops. *Now* I attached a mailbox. example.mbox.gz
Re: Exclusive matching
On 2000.05.24, in [EMAIL PROTECTED],
"David Champion" [EMAIL PROTECTED] wrote:
A look at the source code suggests that this is a misread, though, and
that "^" goes before any pattern component. Well, this pattern:
^~L alice | ^~L bob | ^~L carol
doesn't match anything at all.
I'm still curious about this, but read on.
On 2000.05.24, in [EMAIL PROTECTED],
"Mikko Hänninen" [EMAIL PROTECTED] wrote:
David Champion [EMAIL PROTECTED] wrote on Wed, 24 May 2000:
I briefly tried using parens in a regexp way -- e.g.,
~L (alice|bob|carol)
but that doesn't seem to work at all.
I didn't look into this deeply, but just to throw an idea out --
did you try something like:
^~L (alice|bob|carol)
That was one of the first things I tried, but as you noted below, that
makes Mutt treat the '|' as a pattern separator.
parens just to see what happens, I get "Unmatched ( or \(".
That sounds like a parson problem... Hmm, yes, if you escape the ()'s,
then you need to escape the |'s too, or else they will be seen as as
separating patterns, as opposed to separating expressions within a
single pattern.
OK. I didn't need to escape the parens at all, just the pipes. This
expression is exactly what I'm looking for:
~L alice ~L bob ~L carol ^~L (alice\|bob\|carol)
(I was hoping that the parser would change the meaning of '|' inside
parens -- I didn't think of "\|" because I wasn't looking for a literal
pipe.)
Now, suppose I'm Alice. I'd like to be able to remove the "alice"
parts of that and let $alternates cover it, but I don't see any way to
do that. Is there some way to get $alternates into the expression?
Should there be? I'm happy with a "yes" to either question. :)
Thanks, Mikko!
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
