> So the bug indicates that the length of the slice to be printed is
> wrong. E.g. when you pass the entire buffer.

Which I did. Turns out, for some strange reason, the size of the
replaced string needs to be calculated separately. That seems like a
strange design decision to me but I can live with it.


> I'll have a look or just blindly apply your patches and then take it
> from there. I am not entirely happy with the current solution, and in
> some cases, it seems to cut off the last character.

Yeah, the cut-off happened on the shell: when lines were only
'\n'-terminated as opposed to "proper" \r\n-terminated lines.

Hey, sorry for the delay, and also many thanks for helping out.
The latest changes were a bit rushed. Apologies, I didn't want to cause
you extra work.

> > After "autoscout24.de", there are 455 "ª" (0x00aa).

That's a clear indication of a debug build 😊. 0x00 0xaa ...

> When I initialize `val_buffer` with zeroes,
> var val_buffer: [512]u8 = std.mem.zeroes([512]u8);
> I get many NUL bytes after "autoscout24.de" (instead of "ª"). I don't
> understand why they are printed. Aren't strings NUL-terminated in
> zig!?

Thank you for your patches!

Will apply and release probably in the evening
(local, German time).

Yeah, assuming line length was a bad idea. Thx for the quick fix!

19.02.2024 11:05:26 Max Schillinger <max@mxsr.de>:

> This crash happens at header lines like
> 
> X-Provags-ID: V02:K0:jLG+n5RvqvXDfnaT86MCMCzjw0nIUzH7tOoFF3O0git
> nBPsfi4RZ56LhzW8NuyICLlpqUs+VgNKykpfuZo5jHVjY53Qw=
> =

Thanks to Max Schillinger pointing out some shortcomings,
aercbook now handles more line-continuations, and
base64-encoded (rfc1341) utf-8 names.

Short-Log:

Rene Schallner (2):
      Parser: allow line-continuations with space char
      support rfc1341 utf8

> 2. Line continuations are ignored (only for wrapped contacts?).
> 3. Sometimes contacts are added in a broken way.

> See this example for all three issues at once:

> $ echo 'To: =?UTF-8?B?5byg5LiJ?= <zhang.san@example.com>, "John Doe"
> <john.doe@web.de>, "Schillinger, Max"
> <maximilian.schillinger@example.com>' \
>    | aercbook /tmp/aercbook-test.txt --parse --add-to
>
> Warning error.FileNotFound: /tmp/aercbook-test.txt --> creating it...
>
> Added "John Doe -> "John Doe
> Added =?UTF-8?B?5byg5LiJ?= -> =?UTF-8?B?5byg5LiJ?= <zhang.san@example.com>

> $ cat /tmp/aercbook-test.txt
>
> "John Doe : "John Doe
> =?UTF-8?B?5byg5LiJ?= : =?UTF-8?B?5byg5LiJ?= <zhang.san@example.com>
>
> Searching also has some issues:
>
> 4. Based on `/tmp/aercbook-test.txt`, I get the same output, no matter
> what I search for:
>
> $ aercbook /tmp/aercbook-test.txt zhang
> $ aercbook /tmp/aercbook-test.txt example
> $ aercbook /tmp/aercbook-test.txt xxx
> $ aercbook /tmp/aercbook-test.txt '*'

Thx for bringing that to my attention.

Aercbook is in a "works for me" state.

I will try to update it when I have time, where finding time is the biggest issue, as I am super busy and my need to update is low.

When writing aercbook, I did check out the RFC, trying to cover all relevant cases, and have never had to deal with that weird re-encoding of utf8 names.

But great that you came up with an alternative, so now there are options!

I briefly checked out your solution and its readme. There, I found the statement about the lines of code a bit surprising. I'll probably get rid of the vendored-in args parser and its tests, which would cut sloc in half and we're just a shortcut. If you argue less lines of code are better, e.g. for maintainability (?), you'll probably find that the actual aercbook code is quite straight-forward, explicit, and manageable. Not like an "over 1000 lines of fragile code mess".

But 150 lines of posix shell I find a bit misleading as well because of the sed, awk and even perl dependencies (decoding re-encoded utf8 names). I deliberately didn't want to write aercbook in python (re-using python's lines of code to reduce mine) to avoid dependencies. If you compile aercbook with musl, you get a static executable: 0 runtime dependencies, not even glibc - which I value a lot, using tools like aerc and aercbook in isolated nix (as in NixOS) environments. Such static executables (for baseline CPU architecture) can also be released and copied to other Linux systems and will work there, too, no matter what is installed.

Hi Coco,

Amazing work! Thanks a lot! This is what I was just about to attempt -
and then I saw your flagged message in my aerc 😊. This is just what I
needed! Now I can hack away trying to fix that potential bug I
encountered with commas within FROM names.

Thanks a lot for this great contribuiton!
-Rene
_______________________________________________________________________
On Wed Sep 6, 2023 at 10:30 AM CEST, Coco Liliace wrote:

> ---
> README.md | 6 +++---

_______________________________________________________________________
On Thu Mar 16, 2023 at 5:21 PM CET, Coco Liliace wrote:

> On Wed Mar 8, 2023 at 4:55 PM EST, Coco Liliace wrote:
> > On Wed Dec 28, 2022 at 7:55 AM EST, Rene Schallner wrote:
> > > I just pushed the `zig-0.10` branch which is a tiny back-port of
> > > `zig-master` for the latest "stable" release of zig: zig-0.10. I
> > > downloaded the binary zig-0.10 and verified that it works.
> >
> > Thank you for the work! Can you also make it into a new release please?
> > I'm trying to publish this on the Alpine Linux package repository
> > (aports), and the request just got rejected for not using an actual
> > release:
> >

Hi,

Sorry, my bad! Zig currently is in heavy development and not everything
is stable yet. Regarding aercbook, I used to get away with pointing to
zig-0.9 as being the latest release but this doesn't work anymore.

A few days ago, I pushed the `zig-master` branch to the aercbook
repository which works with the current zig-master (zig-0.11).

I just pushed the `zig-0.10` branch which is a tiny back-port of
`zig-master` for the latest "stable" release of zig: zig-0.10. I
downloaded the binary zig-0.10 and verified that it works.

I'll update the README soon and probably also merge `zig-0.10` into