The eval was unnecessary, and $0 can't be "--".
Tested with /bin/sh on FreeBSD 11.2
---
script/public-inbox-edit | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/script/public-inbox-edit b/script/public-inbox-edit
index 16d7852..6a7d456 100755
--- a/script/public-inbox-edit
+++
Konstantin Ryabitsev wrote:
> On Mon, Jun 10, 2019 at 10:03:20PM +, Eric Wong wrote:
> > Maybe PATCH 14/11 fixes it:
> >
> > https://public-inbox.org/meta/20190610215811.untkksidetf3erf6@dcvr/
>
> It didn't, unfortunately.
>
> > But that won't get you Linux >=3.15 for OFD locks; so Xapian
On Mon, Jun 10, 2019 at 10:03:20PM +, Eric Wong wrote:
Maybe PATCH 14/11 fixes it:
https://public-inbox.org/meta/20190610215811.untkksidetf3erf6@dcvr/
It didn't, unfortunately.
But that won't get you Linux >=3.15 for OFD locks; so Xapian
is probably still using the nasty fork()-based lo
Konstantin Ryabitsev wrote:
> On Mon, Jun 10, 2019 at 07:29:05PM +, Eric Wong wrote:
> > > I did a few successful tests on small trial lists, but I'm running
> > > into a
> > > problem when I try to actually edit something in (a copy of) LKML:
> > >
> > > $ perl5lib/bin/public-inbox-edit -m m
Xapian on Linux <3.15 has trouble with coprocesses since it used
fork() for locking and would hold onto pipes used for git
unnecessarily.
---
I'm not sure if this fixes a problem, actually; but it's a
general cleanliness thing and we already have convuluted logic
in the SearchIdx.pm code for v1
On Mon, Jun 10, 2019 at 07:29:05PM +, Eric Wong wrote:
I did a few successful tests on small trial lists, but I'm running
into a
problem when I try to actually edit something in (a copy of) LKML:
$ perl5lib/bin/public-inbox-edit -m messageid /mnt/fastio/lkml
(mutt opens here)
1 kept, 0 dele
Konstantin Ryabitsev wrote:
> On Mon, Jun 10, 2019 at 03:40:58PM +, Eric Wong wrote:
> > I just noticed, the status message triggers a perl uninitialized
> > warning with multiple epochs, but it's harmless. Will fix in a
> > bit.
>
> I did a few successful tests on small trial lists, but I'
On Mon, Jun 10, 2019 at 03:40:58PM +, Eric Wong wrote:
I just noticed, the status message triggers a perl uninitialized
warning with multiple epochs, but it's harmless. Will fix in a
bit.
I did a few successful tests on small trial lists, but I'm running into
a problem when I try to actu
mutt will set Content-Length, Lines, and Status headers
unconditionally, so we need to account for that before
doing header comparisons to avoid making expensive changes
when noop edits are made.
---
script/public-inbox-edit | 6 ++
t/edit.t | 18 ++
2 files ch
Konstantin Ryabitsev wrote:
> A quick RFE that's beyond the scope of this work, but would be handy from
> the usability perspective -- pass a search term in case multiple messages
> need to be edited. E.g.:
>
> public-inbox-edit -s "john...@example.com" INBOX_DIR
>
> The way I see it working, t
Eric Wong wrote:
> I just noticed, the status message triggers a perl uninitialized
> warning with multiple epochs, but it's harmless. Will fix in a
> bit.
Pushed as 6e507c8cb41b0d48963503a88034348d74506211
--8<-
Subject: [PATCH] edit|purge: improve output on rewrite
On Sun, Jun 09, 2019 at 02:51:47AM +, Eric Wong (Contractor, The Linux
Foundation) wrote:
+public-inbox-edit - edit messages in a public inbox
+
+=head1 SYNOPSIS
+
+ public-inbox-edit -m MESSAGE-ID --all|INBOX_DIR
+
+ public-inbox-edit -F RAW_FILE --all|INBOX_DIR [.. INBOX_DIR]
Konstantin Ryabitsev wrote:
> Thanks, Eric. I'm testing this out now. Quick question -- I'm assuming this
> can't be done online, while new messages are arriving, correct? Should the
> procedure be to stop incoming mail, perform the edits, then start the mail
> again?
It is designed to be done o
On Sun, Jun 09, 2019 at 02:51:36AM +, Eric Wong (Contractor, The Linux
Foundation) wrote:
Some organizations are legally responsible for removing certain
content but prefer to edit out sensitive parts of a message
instead of purging it completely from history.
We can build off existing purg
Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > On Thu, Jun 06, 2019 at 10:10:09PM +, Eric Wong wrote:
> > > > > All those endpoints should detect backpressure from a slow
> > > > > client (varnish/nginx in your case) using the ->getline method.
> > > >
> > > > Wouldn't that spike up and
15 matches
Mail list logo