Re: Mixmaster
On Sun, Jun 28, 2009 at 01:45:24PM +1000, Brian Salter-Duke wrote: > I did quite a bit of work with mixmaster years ago and I think some of > the information in the manual was from me. I am no longer interested in > using mixmaster but I sort of keep an eye on it. Recently I have > returned to using mutt on linux after a spell using it on cygwin. I am > using the Ubuntu package prior to playing around with the latest > release. That Ubuntu package included mixmaster support. That got me > thinking and checking a few things. > > First, is anybody using it? It seems unlikely to me as if they were they > would be complaining about how out of date the manual is. The latest > manual I have to hand (1.5.18) has this to say:- > > "Mixmaster support in mutt is for mixmaster version 2.04 (beta 45 > appears to be the latest) and 2.03. It does not support earlier versions > or the later so-called version 3 betas, of which the latest appears to > be called 2.9b23." (I think I wrote that ages and ages ago). > > According to http://mixmaster.sourceforge.net/ "The current 3.0.x > versions are stable and widely deployed". If the manual is still > correct, and I have no reason to suppose it is not, then mutt does not > work with the latest mixmaster 3.0.x although it probably works with > 2.0.4b46 which is still available via that link (click to go to download > centre). 2.0.4b46 is dated 2002. 3.0.x is dated March 2008. So at the > very least the manual needs updating to read something like:- > > "Mixmaster support in mutt is for mixmaster version 2.03 and 2.04 > (2.0.4b46 is still available from 2002). It does not support earlier > versions or the current version 3.0 (dated March 2008)." > > I hestitate to recommend this change because I do not know whether it is > correct. Maybe the mixmaster code in mutt has been changed. Can anyone > help out with better information? > > Note that I can reply to this in the next 20 hours or so, but will then > be off the internet for 4 days. I will reply on my return. I will not be > ignoring you. Just a small followup to my own post. I found the mixmaster changelog and it appears that mutt support was added to the version 3 beta 25. i.e. not long after the manual article reference was correct. The change made was the introduction of the -T argument to mixmaster which mutt uses. I recall that this was the problem. This change was in 2001-09-14. It looks as if the manual has been wrong for nearly 8 years. I suspect this is an indication of the degree of interest in mixmaster and mutt. We need to know whether it still works and then update the manual. Brian. > Brian. > > -- > "Rectify the anomaly". > The worst slogan used by an education trade union. > Brian Salter-Duke (Brian Duke) Email: b_duke(AT)bigpond(DOT)net(DOT)au -- Brian Salter-Duke (Brian Duke) Email: b_duke(AT)bigpond(DOT)net(DOT)au
Re: Mixmaster
Hi, On Sun, Jun 28, 2009 at 05:17:10PM +1000, Brian Salter-Duke wrote: > Just a small followup to my own post. I found the mixmaster changelog > and it appears that mutt support was added to the version 3 beta 25. > i.e. not long after the manual article reference was correct. The change > made was the introduction of the -T argument to mixmaster which mutt > uses. I recall that this was the problem. This change was in 2001-09-14. > It looks as if the manual has been wrong for nearly 8 years. I suspect > this is an indication of the degree of interest in mixmaster and mutt. > We need to know whether it still works and then update the manual. I'm using mixmaster 3.0.0-2 with mutt 1.5.18-6+b1 on debian lenny and it all works just fine. So the manual seems to be very outdated ;) Regards, sigi
Re: pager_format problem
Hi, * Patrick Shanahan wrote: > not working: > set pager_format="%-.20n: %.40s' '-%Z- %C/%m: %-20.20n %s |" This should have been broken in .18, too. See: http://dev.mutt.org/hg/mutt/file/tip/UPDATING and the entry for 1.5.15: ! format pipe support: format strings ending in | are filtered and go the manual: http://dev.mutt.org/doc/manual.html#formatstrings-filters Rocco
Re: pager_format problem
* Rocco Rutte [06-28-09 12:34]: > > This should have been broken in .18, too. See: > > http://dev.mutt.org/hg/mutt/file/tip/UPDATING but wasn't, at least for me. > and the entry for 1.5.15: > > ! format pipe support: format strings ending in | are filtered > > and go the manual: > > http://dev.mutt.org/doc/manual.html#formatstrings-filters > Thanks, that give a good explanation. I guess there is quite a difference between .18 and .19 and I should use some of the advice I frequently give, read the fine manual egg on face tks, -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org
Re: How to implement save_empty on maildir?
Hi, Rocco Rutte wrote: > * Wu, Yue wrote: >> I want to let mutt deletes empty maildirs automatically, but 'save_empty' >> only >> works for mbox, why? How to achieve it for maildir? > > It doesn't work for maildir. I'm not sure why, but probably because > removing an empty maildir has the potential to break something as it > cannot be done atomically. Mutt can rename the maildir to $maildir-mutt-remove and then remove the subdirectories and then the $maildir-mutt-remove. The rename can be done atomically. Bye, Jörg. -- Es liegt in der Natur des Menschen, vernünftig zu denken und unlogisch zu handeln! Das Gesagte ist nicht das Gemeinte und das Gehörte nicht das Verstandene!
Re: How to implement save_empty on maildir?
On Sun, Jun 28, 2009 at 07:42:53PM +, Jörg Sommer wrote:
> Hi,
>
> Rocco Rutte wrote:
> > * Wu, Yue wrote:
> >> I want to let mutt deletes empty maildirs automatically, but 'save_empty'
> >> only
> >> works for mbox, why? How to achieve it for maildir?
> >
> > It doesn't work for maildir. I'm not sure why, but probably because
> > removing an empty maildir has the potential to break something as it
> > cannot be done atomically.
>
> Mutt can rename the maildir to $maildir-mutt-remove and then remove the
> subdirectories and then the $maildir-mutt-remove. The rename can be done
> atomically.
At first glance, this seems like a good solution, but actually it is
not:
1. There may be an existing directory by that name already.
Even if Mutt checks for the existence of it first, it is not safe,
because the user could (without knowing the behavior of Mutt)
create such a directory in between the time that Mutt checks, and
executes the rename().
2. $maildir may be a symlink. I'm not sure how mutt handles the
general case of a maildir being a symlink, but assuming that's
allowed, then in this case, it would fail briliantly. Mutt would
rename() the symlink, and then delete it. The user may be using
something like fetchmail to deliver mail to the maildir (the actual
directory which was the target of the symlink) in which case Mutt
will NEVER AGAIN see new mail in that directory, at least until
such time as the user realizes what happened and takes some action
to fix the problem. It would effectively make it impossible to use
symlinks.
3. In some cases, it may be possible that the directories $maildir and
${maildir}-mutt-remove would not be on the same file system (e.g.
if $maildir happened to be an NFS mount, or a bind mount, or some
other wacky filesystem, like some arbitrary filesystem
implementation that sits on top of FUSE). In such a case, the
rename() would either fail or not be atomic (since you would need
to copy the files between filesystems in that case). Granted,
doing this is crazy; but as a long-time sysadmin I've known a
surprising number of people who do crazy things with their mail,
simply because they can...
As far as I can see, there is no safe way to atomically ensure that
none of these three cases are true, and in the case of weird file
system implementations, may even be impossible (though, I suppose it
would not be completely unreasonable for Mutt to ignore those cases).
I can't be sure, but I believe it is not possible to implement this
safely on any modern operating system in common usage. However I
believe a better alternative exists: Instead of physically removing
the files, make Mutt simply avoid showing them to you if they contain
no messages. For mbox this is trivial (and yes, I think the behavior
should be consistent between the formats); for maildir you would need
to determine the number of files in each of the subdirectories of
$maildir; or rather determine that there are non-zero numbers of
messages in them.
--
Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpyZoRuJ86UY.pgp
Description: PGP signature
