zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: archived messages with "From " get truncated
Date: Thu, 24 Jun 2021 19:11:56 +0000	[thread overview]
Message-ID: <20210624191156.GC16386@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <20210624083612.GA170692@zira.vinc17.org>

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@chazelas.org> -----
> 
> Date: Wed, 9 Jun 2021 19:16:17 +0100
> From: Stephane Chazelas <stephane@chazelas.org>
> To: Bart Schaefer <schaefer@brasslantern.com>
> Cc: Zsh hackers list <zsh-workers@zsh.org>
> 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@vinc17.net> - 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)
> 


  reply	other threads:[~2021-06-24 19:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24  8:36 Vincent Lefevre
2021-06-24 19:11 ` Daniel Shahaf [this message]
2021-06-24 23:36   ` Vincent Lefevre
2021-06-25  0:15     ` Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210624191156.GC16386@tarpaulin.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).