Hi Bakul,
> The reason being the body was MIME encoded because of UTF-8 even
> though it is plain text.
I think that's why David and others runs all their emails on delivery
through mhfixmsg(1)'s `-decodetext'.
> Content-Transfer-Encoding: base64
Which of us hasn't worked out the possible encod
On 12 Jun 2019 08:46:43 -0600 "Andy Bradford" wrote:
> [ part - text/plain - 577B ]
> Thus said "Valdis Kl?tnieks" on Sat, 08 Jun 2019 21:26:46 -0400:
>
> > In a world of Microsoft Office attachments, is having -search go
> > through the body by default as well still a good idea? Maybe
Thus said "Valdis Kl?tnieks" on Sat, 08 Jun 2019 21:26:46 -0400:
> In a world of Microsoft Office attachments, is having -search go
> through the body by default as well still a good idea? Maybe having a
> separate -searchbody would be better?
Hard to say what it *should* be. In my env
>The bigger issue is that -search seems to blindly match the
>msg body. It doesn't even do mime decoding. So for example the
>body of my prev msg to nmh is base64 encoded (even though it
>is plain text) and -search fails. Unless I specify a search
>pattern of encoded text such as 9uIEJpZyBlbmRpYW!
On Jun 9, 2019, at 1:49 AM, Ralph Corderoy wrote:
>
> Hi Bakul,
>
>> So pick runs -search on header lines as well as the body a header
>> specific option is only run against headers.
>
> pick(1):
>
> This means that the pattern specified for a -search will be found
> everywhere in the mess
Hi Valdis,
> In a world of Microsoft Office attachments, is having -search go
> through the body by default as well still a good idea? Maybe having a
> separate -searchbody would be better?
I think -search should be left alone, but there's previous discussion on
this list about a -header and -bod
Hi Bakul,
> So pick runs -search on header lines as well as the body a header
> specific option is only run against headers.
pick(1):
This means that the pattern specified for a -search will be found
everywhere in the message, including the header and the body, while the
other pattern m
Hi kre,
> > Which it what happens at the moment, so it wouldn't be backwards
> > compatible.
>
> No, it wouldn't - but does anyone really think that matters?
Only to the extent it's worthy of a line in the release notes.
I send myself short emails with leading punctuation in the Subject field
to
Hi Valdis,
> > -search 'Subject[ \t]:[ \t]*\[PATCH [45]\.[0-9]'
>
> [~] grep ^Subject Mail/linux-kernel/321805
> Subject: Re: [PATCH 4.9 04/20] net: Fix for_each_netdev_feature on Big endian
> [~] scan `pick +linux-kernel 321805 -search 'Subject: \[PATCH [45]\.[0-9]'
> -and -from gre...@linux
On Jun 8, 2019, at 6:26 PM, Valdis Klētnieks wrote:
>
> On Sat, 08 Jun 2019 17:17:40 -0700, Bakul Shah said:
>>
>> So pick runs -search on header lines as well as the body a header specific
>> option is only run against headers.
>
> In a world of Microsoft Office attachments, is having -search
On Sat, 08 Jun 2019 17:17:40 -0700, Bakul Shah said:
>
> So pick runs -search on header lines as well as the body a header specific
> option is only run against headers.
In a world of Microsoft Office attachments, is having -search go through the
body by default as well still a good idea? Maybe ha
rg
321805
$ pick +linux-kernel 321805 -search 'Subject: \[WOMBAT [45]\.[0-9]' -and
-from gre...@linuxfoundation.org
pick: no messages match specification
This makes sense. But note that pick does treat header lines specially.
Using your message as an example:
$ grep ^Subject: `m
ck -subject "Stupid 'pick" +info/nmh )
11777 Fri "Valdis Kl?tnieks [nmh-workers] Stupid 'pick' question...<<--=
11778 Fri Bakul Shah Re: [nmh-workers] Stupid 'pick' question...<https://lists.nongnu.org/mailman/listinfo/nmh-workers
Date:Sat, 08 Jun 2019 11:04:27 +0100
From:Ralph Corderoy
Message-ID: <20190608100427.4d1c921...@orac.inputplus.co.uk>
| Which it what happens at the moment, so it wouldn't be backwards
| compatible.
No, it wouldn't - but does anyone really think that matters?
Th
On Fri, 07 Jun 2019 16:19:15 -0700, Bakul Shah said:
> You can directly use search as follows:
>
> -search 'Subject[ \t]:[ \t]*\[PATCH [45]\.[0-9]'
[~] grep ^Subject Mail/linux-kernel/321805
Subject: Re: [PATCH 4.9 04/20] net: Fix for_each_netdev_feature on Big endian
[~] scan `pick +linux-
Hi kre,
> Maybe it would be possible to look for a leading ^ in the user's
> pattern (for other than -search), and if found, remove it, and replace
> the ".*" that's inserted into the RE with "[ \t]*" ?
Sounds like a good idea.
> Certainly no-one who uses a leading ^ is expecting it to attempt
Date:Sat, 08 Jun 2019 08:45:17 +0100
From:Ralph Corderoy
Message-ID: <20190608074517.a586020...@orac.inputplus.co.uk>
| Bakul answered about the anchors.
Maybe it would be possible to look for a leading ^ in the user's
pattern (for other than -search), and if found
Hi Valdis,
> pick -from -subject '\[PATCH [45]\.[0-9]'
...
> However, it *also* catches messages of the form 'Subject: Re: [PATCH
> ' which is unacceptable for the use case in question.
Bakul answered about the anchors. Another approach is to rule out
replies.
-sub foo -and -not -sub r
But more often I just use grep or agrep by cd-ing to the right folder:
cd ~/Mail/
pick + -from -and -subj ... -seq foo
pick foo | xargs agrep -li 'this;that' | xargs scan
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
On Fri, 07 Jun 2019 19:00:52 -0400 "Valdis =?utf-8?Q?Kl=c4=93tnieks?="
wrote:
>
> So trying to work with the linux-kernel mailing list firehose (800-1500
> messages a day), and hitting a problem with 'pick'.
>
> Am trying to match all messages from a given person with a given part of
> a subj
So trying to work with the linux-kernel mailing list firehose (800-1500
messages a day), and hitting a problem with 'pick'.
Am trying to match all messages from a given person with a given part of
a subject line.
pick -from -subject '\[PATCH [45]\.[0-9]'
*almost* does what I want - catch al
21 matches
Mail list logo
