Thanks for the response, Alan.
Before starting, you might want to know your mail software is
somewhat broken:
[snip]
Subject: Re: Trouble with "??"
In-reply-to: Your message of Tue, 29 Oct 1996 12:45:29 EST.
<199610291745(_dot_)MAA14084(_at_)sunspot(_dot_)tiac(_dot_)net>
>
> Haven't used "??" before -- not much on it in the man pages, and
[13 lines snipped]
> PW=`gawk '/^[ ]*[Bb][Ee][Gg][Ii][Nn]/{print $2;exit}' -`
Date: Tue, 29 Oct 1996 10:46:11 -0800
From: "Alan K. Stebbens" <aks(_at_)anywhere(_dot_)engr(_dot_)sgi(_dot_)com>
Somehow, you got that first quote included as part of the
"In-reply-to:" header (no blank line followed, and it was indented,
and it preceded Date: and From:). Most will not see the quote
unless they display headers.
Anyway, back to topic...
Why are you using "gawk" here? The procmail way to do this is:
:0 B
* ^[ ]*begin *\/[^ ]+
{ PW=$MATCH }
"gawk" line was borrowed from working script. I see your point, but
efficiency is not a concern here (this is to handle once-or-twice-
per-week screwups where my game players "Reply" to an error message
without resetting the subject, but are attempting to make a "fixed"
move). It makes more sense for me to have the syntax identical for
the two cases. I'd need a tab in the second [], at least, anyway, to
be equivalent.
People, I've found, reply to the error message in two ways:
(1) to ask for help; and
(2) to attempt to fix their move but forgetting to set
the subject back to what the autoresponder recognizes.
What I'm trying to do is recognize likely cases of (2) and autoreply
that they should resend their move. The "begin followed by a digit"
pattern is the likely indicator here.
You missed the point that I stripped this down for simplicity, and
that the "??" is my concern here. When I get that working, I'll
clean the rest up. I've been on this list for a while now, and I
don't think it was a dumb question, and addressing the sloppinesses
in my test case just distracts (and maybe discourages someone else
who could really tell me why ?? isn't doing what I think it should,
from answering, especially since you can be considered a "reliable
source" not worth refuting in general. I know that when *I* have seen
your response to something, I usually have nothing more to say :) ).
> :0 BiW: nscrab.lock
> * PW ?? ^[0-9]
> ntest_found
Since you are not running a regexp on the body, don't use "B" in the
flags.
Well, I *was* in earlier tests... can't see that it should matter.
If you are running a program called "ntest_found", and
if it doesn't read all of STDIN, then you do need "i", otherwise it
is not used. If you are running a program for its return status,
then use "W".
From your use of the "i" and "W" flags, I'm assuming that "ntest_found"
is a program, and not a file to be filed. If so, then you need to
prefix the program with "|" to show that it is a program invocation:
Well, it *was* a program, but in stripping it down to identify the
problem, "ntest_found" and "ntest_not_found" are just folders
for testing. I didn't nuke all the nukable flags, but they shouldn't
affect the test results.
FYI, what I want to do is send out something like:
You appear to have responded to an error message with a
new move, but did not reset the subject. If that was
the case, you should resend your move with the correct
subject. If not, the mail has been put in my mailbox and
I will answer it as soon as I can.
As for the failing match, it may be because '^' or '??' didn't work well
together, if at all.
Well, *that's* the real problem, and what I was writing about!
There are still problems with some regexp
expressions after a '??'. A common work-around is to parenthesize
the regexp.
Here's how the recipe should look (if my assumptions are correct):
:0iW:nscrab.lock
* PW ?? (^[0-9])
| ntest_found
I tried that -- same result :-(
You can upgrade to the latest version of procmail yourself, for testing
purposes, but it would also be appropriate for your ISP to upgrade
also.
Actually, I can't -- am hanging on the edge of disk space limits --
but I think they'll upgrade. I was hoping for info as to whether
that will fix this.
The "else" clause should then be explicitly so:
:0 ei:nscrab.lock
| ntest_not_found
Umm, isn't this religion? Consider some "C" code:
int func1 (int x) { if(x) return 1; else return 0; }
int func2 (int x) { if(x) return 1; return 0; }
Is there a (non-stylistic) reason we need your "else"?
Cheers,
Stan.