Re: Colouring deletions [Was: mail box vanished]
On 12Aug2014 14:11, Gary Johnson garyj...@spocom.com wrote: On 2014-08-12, Gary Johnson wrote: Something else worth mentioning is that the effect of these rules depends on the order in which they are defined. Later rules supersede earlier rules. I didn't say that very well. Rules are executed in the order in which they are defined, so later rules are executed after earlier rules and their coloring may replace that of earlier rules. Aye, very important especially when debugging rules that seem not to be working. Another nuance is that the index rules match a pattern and colour the entire index line. By contract, the body rules match a regexp and colour only the macthed section, so my FAIL body rules just colour the word FAIL in red. Which I think is good! Cheers, Cameron Simpson c...@zip.com.au All the doors in this ship have nice sunny dispositions. It is their pleasure to open for you, and their satisfaction to close with the knowledge of a job well done. - Marvin _The Hitchhiker's Guide to the Galaxy_
Re: Colouring deletions [Was: mail box vanished]
On 2014-08-12, Cameron Simpson wrote: On 11Aug2014 19:36, Erik Christiansen wrote: On 11.08.14 09:33, Cameron Simpson wrote: I colour deleted messages in dark blue (and my terminal has a black background) so that at least makes such accidents visually obvious. That looks useful. I tried a quick: :color index black default ^[0-9]+..D but that coloured neither the pre-existing deleted messages, nor one subsequently deleted. Is your working solution very different? I use: color index blue black ~D I see someone's already mentioned Patterns to you instead of regexps:-) In case anyone cares, I list my colour scheme below. Bear in mind I work in green-on-black terminals. The main points of interest are: - new messages get cyan index lines - more visible than read messages - serious warning messages from monitoring systems get red index lines - message bodies colour (FAIL|ERROR|CRITICAL|DOWN) in red also Something else worth mentioning is that the effect of these rules depends on the order in which they are defined. Later rules supersede earlier rules. Regards, Gary
Colouring deletions [Was: mail box vanished]
On 11.08.14 09:33, Cameron Simpson wrote: I colour deleted messages in dark blue (and my terminal has a black background) so that at least makes such accidents visually obvious. That looks useful. I tried a quick: :color index black default ^[0-9]+..D but that coloured neither the pre-existing deleted messages, nor one subsequently deleted. Is your working solution very different? Erik -- Time is a great teacher, but unfortunately it kills all its pupils. - Hector Louis Berlioz
Re: mail box vanished
On 01Aug2014 07:51, Ulrich Lauther ulrich.laut...@t-online.de wrote: On Thu, Jul 31, 2014 at 09:45:15PM -0400, Jon LaBadie wrote: Do you have a remote client getting mail from that mailbox which isn't configured to keep the mail on the server? no, I just retrieve mail from two providers using /usr/bin/fetchmail -a -U -d 30 -L /var/log/fetchmail.log \ --auth password \ -m '/usr/bin/procmail -d %T' procmail stores into /var/mail/user and the only other program that - to my knowledge - accesses that file is mutt. To prevent further losses, I now added a .procmailrc requesting procmail to make a copy into another file. I fetch my email like you (but using getmail) and deliver it to a mail folder literally named spool in with my regular mail folders. This keeps it away from the local mail spool, which can be subject to locking issues (never the same on all systems:-) and special ownerships (eg group writable by the local mail system). Some things to check: is the freshly truncated mail spool the same file as before you started mutt? When you start mutt, is the mail folder empty immediately or only after you close mutt? Might there be some race condition between mutt's access and some other process (though I imagine you've considered that). Does the local mail system deliver to this spool file, or is it only procmail? Cheers, Cameron Simpson c...@zip.com.au The criterion of truth is that it works even if nobody is prepared to acknowledge it. - Ludwig von Mises
Re: mail box vanished
On Fri, Aug 01, 2014 at 07:51:03AM +0200, Ulrich Lauther wrote: On Thu, Jul 31, 2014 at 09:45:15PM -0400, Jon LaBadie wrote: Do you have a remote client getting mail from that mailbox which isn't configured to keep the mail on the server? no, I just retrieve mail from two providers using /usr/bin/fetchmail -a -U -d 30 -L /var/log/fetchmail.log \ --auth password \ -m '/usr/bin/procmail -d %T' any kind of ill behaved tmp cleaner? Is the mbox accidentally softlinked to non-persistent storage (tmpfs)? Richard --- Name and OpenPGP keys available from pgp key servers
Re: mail box vanished
On Fri, Aug 01, 2014 at 10:40:05AM +0200, Ulrich Lauther wrote: On Fri, Aug 01, 2014 at 10:33:27AM +0200, Ulrich Lauther wrote: Is there a way to mark - accidentally - all messages as read? I should have said: Is there a way to mark - accidentally - all messages as read or deleted? Not sure what *you* mean by accidentally, but pressing the wrong key(s) is one way. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X
Re: mail box vanished
On Fri, Aug 01, 2014 at 10:06:53PM +1200, Chris Bannister wrote: On Fri, Aug 01, 2014 at 10:40:05AM +0200, Ulrich Lauther wrote: On Fri, Aug 01, 2014 at 10:33:27AM +0200, Ulrich Lauther wrote: Is there a way to mark - accidentally - all messages as read? I should have said: Is there a way to mark - accidentally - all messages as read or deleted? Not sure what *you* mean by accidentally, but pressing the wrong key(s) is one way. Yes, that's what I meant. Is there such a key? I couldn't find one. ulrich
mail box vanished
Sorry, this message may not directly be mutt-related, but maybe somebody can point me to better place to ask. Within a time span of (probably) some weeks the file /var/spool/mail/my account for the second time suddenly has size 0. Of course, without myself doing anything evil, probably without doing anything at all, other than starting mutt. The sytem is precise1-Ubuntu SMP. Any ideas? Kind regards, ulrich
Re: mail box vanished
On Thu, Jul 31, 2014 at 09:23:56PM +0200, Ulrich Lauther wrote: Sorry, this message may not directly be mutt-related, but maybe somebody can point me to better place to ask. Within a time span of (probably) some weeks the file /var/spool/mail/my account for the second time suddenly has size 0. Of course, without myself doing anything evil, probably without doing anything at all, other than starting mutt. The sytem is precise1-Ubuntu SMP. Any ideas? Do you have a remote client getting mail from that mailbox which isn't configured to keep the mail on the server? jl -- Jon H. LaBadie mut...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (609) 477-8330 (C)
