Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: archived messages with "From " get truncated



Vincent Lefevre wrote on Thu, Jun 24, 2021 at 10:36:12 +0200:
> Below is a message that was sent by Stephane to workers.
> It has been archived here:
> 
>   https://www.zsh.org/mla/workers/2021/msg01272.html
> 
> but got truncated just before a line starting with "From ".
> It seems that the mail archive software is buggy, thinking
> that this starts a new mail message.

The problem might be either in the mailing list software or in how we
invoke it.

We invoke mhonarc as follows:

   134          /usr/local/bin/mhonarc \
   135                  -quiet \
   136                  -definevar listlocalpartsansprefix=${listlocalpart#zsh-} \
   137                  -title  "${title}" \
   138                  -ttitle "${title}" \
   139                  -tlevels 9999 \
   140                  -rcfile /usr/local/www/mhonarc.zsh \
   141                  -add \
   142                  -- "$munged_tmpfile" \
   143            || exit EX_UNAVAILABLE

Here, ${munged_tmpfile} is a file that was created by
«() { munged_tmpfile=$1; cat > $munged_tmpfile } =(:)», the whole thing
being invoked by Exim using a «"| /path/to/script"» target in
/etc/aliases.  (The "munged" terminoilogy is because there's also
a «perl -pi -E 's/^X-Seq: …/…/ if (1../^$/)'» in there.)

Does anyone happen to see off the top of their heads what we're doing
wrong?

We still have the original message and can regenerate the archives once
we've fixed the intake problem.

mhonarc v2.6.24.

Thanks for the report, Vincent.

Daniel


> In the archives, there is a risk that this message gets truncated
> in the forwarded message below, for the same reason. For those who
> read the archive, one has, with quotes to avoid the truncation:
> 
> [...]
> > Why would one write print foo >&- in the first place, other than
> > to check whether print reports error or not (and in that regard,
> > the behaviour is very misleading)
> > 
> > From looking at the history, it looks more like:
> > 
> > 1990 (1.0) echo ignores write failures (by design or not).
> [...]
> 
> ----- Forwarded message from Stephane Chazelas <stephane@xxxxxxxxxxxx> -----
> 
> Date: Wed, 9 Jun 2021 19:16:17 +0100
> From: Stephane Chazelas <stephane@xxxxxxxxxxxx>
> To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
> Cc: Zsh hackers list <zsh-workers@xxxxxxx>
> Subject: Re: [BUG] builtin echo doesn't check write error
> 
> 2021-06-09 09:13:42 -0700, Bart Schaefer:
> [...]
> > My (possibly poor) recollection is that this was made this way in part
> > for ports to environments that don't have a /dev/null device
> 
> While that sounds like a very plausible reason for the original
> behaviour whereby "print" would not report any write error,
> that doesn't really tie up with the current behaviour where
> the error is supressed only when print/echo's stdout is
> explicitly closed.
> 
> Why would one write print foo >&- in the first place, other than
> to check whether print reports error or not (and in that regard,
> the behaviour is very misleading)
> 
> From looking at the history, it looks more like:
> 
> 1990 (1.0) echo ignores write failures (by design or not).
> 1999 workers/9129 Peter writes the "print foo >&-" succeeds, no
>      error test case, just documenting the actual behaviour of
>      print ignoring errors (here using >&- as the easiest way to
⋮
> 
> ----- End of forwarded message -----
> 
> -- 
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 




Messages sorted by: Reverse Date, Date, Thread, Author