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
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
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
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
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
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,
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
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
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
We don't want to serialize timestamps as strings to JSON.
I only noticed this bug on a 32-bit system.
---
lib/PublicInbox/Git.pm | 2 +-
t/www_listing.t| 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/PublicInbox/Git.pm b/lib/PublicInbox/Git.pm
index
14 matches
Mail list logo
