Odd 'new mail' effect on new system
My shell account provided by my web hosting company has been moved from a FreeBSD system to a much more modern Linux system. They have installed mutt (1.5.17 I think) for use there, I was using my own build of mutt 1.5.16 on the old BSD system. It all works pretty much the same (no change of home directory so my muttrc is the same one) except that every time I send a mail message mutt tells me there's new mail in my sentmail folder - true enough but not very helpful! It didn't do that on the BSD system. What do I need to do to fix this - or what can I do to diagnose what's going on? -- Chris Green
Re: Odd 'new mail' effect on new system
Hi Chris! On Thu, 06 Dec 2007, Chris G wrote: It all works pretty much the same (no change of home directory so my muttrc is the same one) except that every time I send a mail message mutt tells me there's new mail in my sentmail folder - true enough but not very helpful! It didn't do that on the BSD system. What do I need to do to fix this - or what can I do to diagnose what's going on? Have you specified your sentmail folder as mailbox in your .muttrc? regards, Christian -- Excerpt from a conversation with a friend, early in my unix odyssey: So now I've got all these floppy-sized archive pieces, and I haven't been able to figure out what program I'm supposed to use to concat-- er, never mind.
Re: Odd 'new mail' effect on new system
On Thu, Dec 06, 2007 at 11:21:17AM +0100, Christian Brabandt wrote: Hi Chris! On Thu, 06 Dec 2007, Chris G wrote: It all works pretty much the same (no change of home directory so my muttrc is the same one) except that every time I send a mail message mutt tells me there's new mail in my sentmail folder - true enough but not very helpful! It didn't do that on the BSD system. What do I need to do to fix this - or what can I do to diagnose what's going on? Have you specified your sentmail folder as mailbox in your .muttrc? I don't *think* so, and anyway why would it change on the change of OS, the muttrc is the same file - still works on the old FreeBSD system. . but, yes, you're right, I have :- set record=~/Mail/sentmail ... ... ... mailboxes ~/Mail/inbox `echo ~/Mail/lists/*` `echo ~/Mail/*` `echo ~/Mail/spam/*` ... but why don't I see 'new mail' in ~/Mail/sentmail on the FreeBSD system? Anyway it's fairly easy to fix, I can just move my sentmail somewhere else, or simpler remove the `echo ~/Mail/*` from mailboxes as there's nothing else there which receives new mail now. Thanks for the pointer. -- Chris Green
Re: Odd 'new mail' effect on new system
On Thu, Dec 06, 2007 at 10:32:24AM +, Chris G wrote: On Thu, Dec 06, 2007 at 11:21:17AM +0100, Christian Brabandt wrote: Hi Chris! On Thu, 06 Dec 2007, Chris G wrote: It all works pretty much the same (no change of home directory so my muttrc is the same one) except that every time I send a mail message mutt tells me there's new mail in my sentmail folder - true enough but not very helpful! It didn't do that on the BSD system. What do I need to do to fix this - or what can I do to diagnose what's going on? Have you specified your sentmail folder as mailbox in your .muttrc? I don't *think* so, and anyway why would it change on the change of OS, the muttrc is the same file - still works on the old FreeBSD system. . but, yes, you're right, I have :- set record=~/Mail/sentmail ... ... ... mailboxes ~/Mail/inbox `echo ~/Mail/lists/*` `echo ~/Mail/*` `echo ~/Mail/spam/*` ... but why don't I see 'new mail' in ~/Mail/sentmail on the FreeBSD system? I have just realised (I think) why it has changed. The sentmail folder is in mbox format and the file system is mounted with the noatime flag so mutt can't *reliably* detect new mail. It would appear that on FreeBSD it reliably *can't* detect new mail but, for some reason, on the more modern Linux system it *can* detect new mail in that folder. -- Chris Green
Re: searching in sent
Hi, yes, absolutely; ~b stas does find stas What I mean is that when I am in my inbox folder, I usually have to look for an email from somebody; what I usually do is to look for that somebody and then order the folder according to the sender, this way I can quickly look for the email I was looking for. Whilst in inbox this is as easy as / stas enter oo, in sent, when I do / stas enter mutt doesn't find anything even if I have 250 emails from that person. Since the only obvious difference between inbox and sent is that To: field, I thought this could be the problem. In any case, now I have set default_hook=(~f %s !~P) | (~P ~C %s) | ~s %s in my muttrc and still / stas does not yield any result. I don't understand the ~s part of it, what's is it piping into? Thanks, Pau PS: Of course, I can always do ~ b stas, but I like to understand what the problem is 2007/12/5, Kyle Wheeler [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, December 5 at 12:03 AM, quoth Nicolas Rachinsky: * Kyle Wheeler [EMAIL PROTECTED] [2007-12-04 16:39 -0600]: Searching in any index (sent, inbox, whatever) relies on the value of $default_hook, which defaults to ~f %s !~P | (~P ~C %s). I think you mean $simple_search with the default ~f %s | ~s %s. Right! Sorry, my mistake. ~Kyle - -- He who dares not offend cannot be honest. -- Thomas Paine -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHVd9/BkIOoMqOI14RArtWAKDdpwuS+SEfC23WHf5NKMH1dgpJrwCgpaRG wssRcSWme4EGCEzHfBIrvso= =ojUG -END PGP SIGNATURE-
Re: searching in sent
[please do not top-post] * Pau Amaro-Seoane [EMAIL PROTECTED] [2007-12-06 12:41 +0100]: I think you mean $simple_search with the default ~f %s | ~s %s. Right! Sorry, my mistake. In any case, now I have set default_hook=(~f %s !~P) | (~P ~C %s) | ~s %s in my muttrc and still / stas does not yield any result. I don't understand the ~s part of it, what's is it piping into? Why did you set default_hook and not simple_search? This is mentioned in the mail you are replying to. Nicolas -- http://www.rachinsky.de/nicolas
Seg fault on redirection
Hi, Segmentation fault occurs when using the operator on command line: ~/temp/usr/bin/mutt [EMAIL PROTECTED] Testbody Looking up localhost... Connecting to localhost... Authenticating (LOGIN)... Segmentation fault How ever if ~/temp/usr/bin/mutt [EMAIL PROTECTED] is used and we go through the normal(ui) mode it is seen that the mail is sent successfully Linux distribution is Debian testing ~/tempmutt -v Mutt 1.5.17 (2007-11-01) Copyright (C) 1996-2007 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 2.6.22-3-686 (i686) ncurses: ncurses 5.6.20071013 (compiled with 5.6) libidn: 1.1 (compiled with 1.1) hcache backend: GDBM version 1.8.3. 10/15/2002 (built Apr 24 2006 03:25:20) Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_INODESORT +USE_POP +USE_IMAP +USE_SMTP -USE_GSS -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/usr/share/mutt SYSCONFDIR=/etc EXECSHELL=/bin/sh MIXMASTER=mixmaster To contact the developers, please mail to [EMAIL PROTECTED]. To report a bug, please visit http://bugs.mutt.org/. patch-1.5.13.cd.ifdef.2 patch-1.5.13.cd.purge_message.3.4 patch-1.5.13.nt+ab.xtitles.4 patch-1.5.4.vk.pgp_verbose_mime patch-1.5.6.dw.maildir-mtime.1 patch-1.5.8.hr.sensible_browser_position.3 Thanks Mathew
Reliable/safe way of removing empty maildirs?
What's a reliable way of removing empty maildirs? Presumably it's possible but you'd have to follow some protocol that wouldn't interfere with the proper writing of messages to the maildir. Or is it simply not possible, in which case the wonderful concept of maildir not needing file locking is rather less wonderful IMHO. -- Chris Green
Re: searching in sent
and yet I would love to get rid of the To: thing... I don't have a From: in my inbox... it's a word repeated unnecessary as many times as email I have sent... I know I have sent them, it's the SENT folder... 2007/12/6, Pau Amaro-Seoane [EMAIL PROTECTED]: Why did you set default_hook and not simple_search? This is mentioned in the mail you are replying to. Nicolas -- http://www.rachinsky.de/nicolas because I am preparing a big move to another country and I didn't look carefully? my excuses, my fault thanks a lot Pau
locale and external address
I've an address for outgoing mail (with my provider's domain) and a local one ([EMAIL PROTECTED]). When I send local mail, in the header I fond always, as From field, the external address. There is a way to tell Mutt to use the external address only for outgoing emails and the internal one for local mail? Thanx MS -- linux user no.: 353546 public key at http://keyserver.linux.it
Re: searching in sent
Why did you set default_hook and not simple_search? This is mentioned in the mail you are replying to. Nicolas -- http://www.rachinsky.de/nicolas because I am preparing a big move to another country and I didn't look carefully? my excuses, my fault thanks a lot Pau
Re: searching in sent
* Pau Amaro-Seoane [EMAIL PROTECTED] [2007-12-06 14:15 +0100]: and yet I would love to get rid of the To: thing... I don't have a From: in my inbox... it's a word repeated unnecessary as many times as email I have sent... I know I have sent them, it's the SENT folder... Redefine $index_format in your sent folder. Nicolas -- http://www.rachinsky.de/nicolas
Re: Saving outgoing and incoming messages in same folder
=- John Magolske wrote on Wed 5.Dec'07 at 20:50:00 -0800 -= I was ready to send this message as a question to the list when one last round of searching brought this answer...figured I'd send it anyway to maybe increase the odds of finding for others searching out a similar solution. John++ I tried it without the ' ' quotes: folder-hook . set record=^ which also seems to work. Is there a reason those additional quotes should be included? For quoting see DebugConfig and MuttGuide / Syntax and PatternQuoting on wiki. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: Reliable/safe way of removing empty maildirs?
=- Chris G wrote on Thu 6.Dec'07 at 13:03:13 + -= What's a reliable way of removing empty maildirs? Presumably it's possible but you'd have to follow some protocol that wouldn't interfere with the proper writing of messages to the maildir. chmod a-w dir/new rm -rf dir -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: locale and external address
=- Mauro Sacchetto wrote on Thu 6.Dec'07 at 14:16:02 +0100 -= I've an address for outgoing mail (with my provider's domain) and a local one ([EMAIL PROTECTED]). When I send local mail, in the header I fond always, as From field, the external address. There is a way to tell Mutt to use the external address only for outgoing emails and the internal one for local mail? Yes, read about the various hooks in manual.txt. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: Reliable/safe way of removing empty maildirs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, December 6 at 04:46 PM, quoth Rado S: =- Chris G wrote on Thu 6.Dec'07 at 13:03:13 + -= What's a reliable way of removing empty maildirs? Presumably it's possible but you'd have to follow some protocol that wouldn't interfere with the proper writing of messages to the maildir. chmod a-w dir/new rm -rf dir Well, that's not *quite* safe, now is it? There's a race condition between deciding that a maildir is empty and then changing the permissions such that no one can deliver mail to it. It would have to be more like this: chmod a-w dir/new if [ `find dir -type f` ] ; then echo Not empty! chmod a+w dir/new else rm -rf dir fi ~Kyle - -- I think we ought always to entertain our opinions with some measure of doubt. I shouldn't wish people dogmatically to believe any philosophy, not even mine. -- Bertrand Russell -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHWB1IBkIOoMqOI14RAp8LAJ0YXKrpUr9TCwaswVpky/MF8UH6rACgiECX 1CKaU1As7wX9YrRyQPy50Cw= =ibUG -END PGP SIGNATURE-
Re: Reliable/safe way of removing empty maildirs?
On Thu, Dec 06, 2007 at 10:03:20AM -0600, Kyle Wheeler wrote: On Thursday, December 6 at 04:46 PM, quoth Rado S: =- Chris G wrote on Thu 6.Dec'07 at 13:03:13 + -= What's a reliable way of removing empty maildirs? Presumably it's possible but you'd have to follow some protocol that wouldn't interfere with the proper writing of messages to the maildir. chmod a-w dir/new rm -rf dir Well, that's not *quite* safe, now is it? There's a race condition between deciding that a maildir is empty and then changing the permissions such that no one can deliver mail to it. It would have to be more like this: chmod a-w dir/new if [ `find dir -type f` ] ; then You have to do something like this instead: found=`find dir -type f` if -n $found ; then At least on my system (Mac OS X 10.3 = Darwin 7.9.0), where find(1) exits with status 0 even if nothing is found. echo Not empty! chmod a+w dir/new else rm -rf dir fi ~Kyle Paul. -- Paul Hoffman [EMAIL PROTECTED]
Re: Reliable/safe way of removing empty maildirs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, December 6 at 11:40 AM, quoth Paul Hoffman: chmod a-w dir/new if [ `find dir -type f` ] ; then You have to do something like this instead: found=`find dir -type f` if -n $found ; then At least on my system (Mac OS X 10.3 = Darwin 7.9.0), where find(1) exits with status 0 even if nothing is found. That's why I used the form that I used. Consider what I said; I said if [ `find dir -type f` ] ; then I did not say: if find dir -type f ; then The reason is because the former relies on the output of find, and the latter relies on the exit status of find. In other words, I had already addressed this issue. At worst, some shells might require that to be rewritten like this: if [ $( find dir -type f ) ] ; then The reason for that is that [ (also known as /bin/test, and frequently a builtin shell command) returns true if it has any arguments of any non-zero length, and returns false if it does not (i.e. the -n argument is the default behavior). My example is equivalent to this: found=`find dir -type f` if [ $found ] ; then ...but does not require the extraneous variable definition. Your alternative suggestion: if -n $found ; then will, unfortunately, not work in many situations because in many POSIX shells (including bash), -n is not a valid argument to the if keyword, nor is -n a recognized executable program or command. Perhaps in your system you have a /bin/-n program, but most folks don't. ~Kyle - -- Many who claim to have been transformed by Christ's love are deeply, even murderously, intolerant of criticism. -- Sam Harris -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHWDXJBkIOoMqOI14RAj1CAJsETNaVb1dj9M9kNyvsy1tKjcHD2QCfRZVu +DLO3JgxGFwm5u70aTy7BU4= =Xgwv -END PGP SIGNATURE-
Re: Reliable/safe way of removing empty maildirs?
On Thu, Dec 06, 2007 at 11:40:04AM -0500, Paul Hoffman wrote: On Thu, Dec 06, 2007 at 10:03:20AM -0600, Kyle Wheeler wrote: On Thursday, December 6 at 04:46 PM, quoth Rado S: =- Chris G wrote on Thu 6.Dec'07 at 13:03:13 + -= What's a reliable way of removing empty maildirs? Presumably it's possible but you'd have to follow some protocol that wouldn't interfere with the proper writing of messages to the maildir. chmod a-w dir/new rm -rf dir Well, that's not *quite* safe, now is it? There's a race condition between deciding that a maildir is empty and then changing the permissions such that no one can deliver mail to it. It would have to be more like this: chmod a-w dir/new if [ `find dir -type f` ] ; then You have to do something like this instead: found=`find dir -type f` if -n $found ; then Ack! Sorry, I meant: if [ -n $found ]; then At least on my system (Mac OS X 10.3 = Darwin 7.9.0), where find(1) exits with status 0 even if nothing is found. echo Not empty! chmod a+w dir/new else rm -rf dir fi ~Kyle Paul. Paul. -- Paul Hoffman [EMAIL PROTECTED]
Re: Reliable/safe way of removing empty maildirs?
On Thu, Dec 06, 2007 at 11:47:53AM -0600, Kyle Wheeler wrote: On Thursday, December 6 at 11:40 AM, quoth Paul Hoffman: chmod a-w dir/new if [ `find dir -type f` ] ; then You have to do something like this instead: found=`find dir -type f` if -n $found ; then At least on my system (Mac OS X 10.3 = Darwin 7.9.0), where find(1) exits with status 0 even if nothing is found. That's why I used the form that I used. Consider what I said; I said if [ `find dir -type f` ] ; then I did not say: if find dir -type f ; then The reason is because the former relies on the output of find, and the latter relies on the exit status of find. In other words, I had already addressed this issue. Right, sorry. I was going to say to use the exit status of find(1), but then realized that wouldn't help. At worst, some shells might require that to be rewritten like this: if [ $( find dir -type f ) ] ; then Or using backticks: if [ `find dir -type f` ]; then I don't know if that's any more portable, though. The reason for that is that [ (also known as /bin/test, and frequently a builtin shell command) returns true if it has any arguments of any non-zero length, and returns false if it does not (i.e. the -n argument is the default behavior). Thanks -- I didn't know that. My example is equivalent to this: found=`find dir -type f` if [ $found ] ; then ...but does not require the extraneous variable definition. Hmm, my test (builtin, bash 2.05b.0) can't be relied upon: $ PS1='\n\$ ' $ mkdir foo; cd foo /User/nkuitse/dt/foo $ builtin test `find . -type f` || echo No files OK-- No files $ touch bar $ builtin test `find . -type f` || echo No files OK-- $ touch baz $ builtin test `find . -type f` || echo No files bash: test: ./bar: unary operator expected Oops! -- No files /bin/test messes up in the same way, just with a different error message. YMMV of course. ~Kyle Paul. -- Paul Hoffman [EMAIL PROTECTED]
Re: Mixmaster
* Brian Salter-Duke [EMAIL PROTECTED] [06.12.07 21:31]: Is anyone using the mixmaster support in mutt? I ask merely because I was involved in improving this about 7 years ago, and I'm curious. I have no intention of ever using it again. The support is for a very old version of Mixmaster and not for the more recent version 3 betas. Should Mixmaster support be kept? It is unlikely to carry on working even with the old mixmaster code (version 2.4 beta 46 from September 2002), and that code may soon be not available. Brian. * Ciò letto, correndo giovedì 06 dicembre 2007, alle 21 e 38 rispondo così: Last Mixmaster changes are dated 2007 september, see: http://svn.noreply.org/svn/mixmaster/trunk/Mix/HISTORY I would like to use mixmaster support, yes. I wrote also a complete reference guide* for using mixmaster with Mutt, but it's kept in stand-by, because of incompatibility between recent versions of Mutt and Mixmaster. It's an ideal argument for a flame war... anonimity: good or bad? IMHO it's good in some situations. In the country where I live, others are the instruments to protect yourself from abuse, crimes, ecc.. So I like Mixmaster as matter of study, in some sense. In other countries, perhaps, anonimity could be matter of life. * in italian and as a part of Il Nirvana con Mutt (see website in sig). ciao Ataualpa aka Francesco Ciattaglia. -- - Linux is better: Open Free! || www.ataualpa.altervista.org
Re: Reliable/safe way of removing empty maildirs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, December 6 at 03:31 PM, quoth Paul Hoffman: Or using backticks: if [ `find dir -type f` ]; then I don't know if that's any more portable, though. Backticks aren't any more portable, I don't think... but it doesn't matter too much. However the double-quotes there solve the problem that you note: Hmm, my test (builtin, bash 2.05b.0) can't be relied upon: $ PS1='\n\$ ' $ mkdir foo; cd foo /User/nkuitse/dt/foo $ builtin test `find . -type f` || echo No files OK-- No files $ builtin test `find . -type f` || echo No files No files $ touch bar $ builtin test `find . -type f` || echo No files OK-- $ touch bar $ builtin test `find . -type f` || echo No files $ touch baz $ builtin test `find . -type f` || echo No files bash: test: ./bar: unary operator expected Oops! -- No files $ touch baz $ builtin test `find . -type f` || echo No files The reason for the problem is that the shell is evaluating things twice. In essence, the output of find is substituted for `find . -type f` in its raw form. You'd get the same problem if you did this: $ foo= $ builtin test $foo echo full || echo empty empty $ foo=one $ builtin test $foo echo full || echo empty full $ foo=one two $ builtin test $foo echo full || echo empty -bash: test: one: unary operator expected empty That last command is equivalent, to the shell, to the following command: $ builtin test one two echo full || echo empty In order to get the result you want, i.e. to test whether foo contains text, you have to quote it: $ builtin test $foo echo full || echo empty This specifies that no matter what's in foo, it's part of a single quoted string that is passed as the only argument to test. The same thing is true of anything that the shell evaluates, including backtick expansion. In other words, the following two commands behave the same way: $ test $foo echo full || echo empty $ test `echo $foo` echo full || echo empty ... and they both have the same solution: encapsulate whatever it is inside quotes: $ test $foo echo full || echo empty $ test `echo $foo` echo full || echo empty Heh, ain't the shell grand? ~Kyle - -- Nonsense. Space is blue and birds fly through it. -- Heisenberg -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHWGUJBkIOoMqOI14RAt59AKCZOYtUjkEemFpLm2lZK1vr6XCmTgCcDEOe w+PrVIPulkGo+xatxk5x8g4= =m/9g -END PGP SIGNATURE-
Re: Reliable/safe way of removing empty maildirs?
chmod a-w dir/new
if [ `find dir -type f` ] ; then
You have to do something like this instead:
[snip other responses]
Perhaps I've misunderstood the reason for doing this, but I would just
ask find to do a rmdir, and let it fail if the directory isn't empty.
find dir -depth -type d -exec rmdir {} \;
If 'dir' is still around when that finishes, it's probably because
there's a file in there now. In the meantime, it's removed all empty
subtrees.
--
Darren Dunham [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
This line left intentionally blank to confuse you.
Re: locale and external address
Alle giovedì 6 dicembre 2007, Rado S ha scritto: I've an address for outgoing mail (with my provider's domain) and a local one ([EMAIL PROTECTED]). When I send local mail, in the header I fond always, as From field, the external address. There is a way to tell Mutt to use the external address only for outgoing emails and the internal one for local mail? Yes, read about the various hooks in manual.txt. I tried the following: send-hook '~t [EMAIL PROTECTED]' 'my_hdr From: Mutt User [EMAIL PROTECTED]' to send local email (the domain is debian) having [EMAIL PROTECTED] as sender, but it doesn't work. There is a misteke in format? Note that I'm using exim4 on Debian Sid, which has the habit of get the address from /etc/email.addesses rather from .muttrc... Thanx MS -- linux user no.: 353546 public key at http://keyserver.linux.it
Re: Reliable/safe way of removing empty maildirs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday, December 6 at 09:15 PM, quoth A Darren Dunham:
Perhaps I've misunderstood the reason for doing this, but I would
just ask find to do a rmdir, and let it fail if the directory isn't
empty.
find dir -depth -type d -exec rmdir {} \;
If 'dir' is still around when that finishes, it's probably because
there's a file in there now. In the meantime, it's removed all empty
subtrees.
That would work flawlessly on MH directories, but Maildir's are
slightly more complicated---they consist of several directories. Your
find command will indeed not erase mail that was delivered right when
you wanted it to be, however it will corrupt the Maildir.
For example, if I think I have an empty Maildir named dir, then
on-disk it should look like this:
dir/
+- cur/
+- new/
`- tmp/
If, without my knowledge, email was delivered to it, it will look like
this:
dir/
+- cur/
+- new/
| `- a_message_file
`- tmp/
If I then run your find command, it will delete the two empty
components (tmp and cur) and will leave me with an unreadable
corrupted Maildir that looks like this:
dir
`- new
`- a_message_file
I would have to realize what has happened and then re-create the
missing directories in order to make things behave properly.
So, you're right that your command doesn't irrecoverably destroy
email... but it's still not very convenient.
~Kyle
- --
We are all worms, but I do believe I am a glow worm.
-- Winston Churchill
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!
iD8DBQFHWG6GBkIOoMqOI14RAgA0AJ95IP1zV0NNy0LZGvn6QOHOweS3GgCgoPrw
8qI9KmQwaWDPT804NGTI5Wk=
=BUoH
-END PGP SIGNATURE-
Re: locale and external address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, December 6 at 10:36 PM, quoth Mauro Sacchetto: Alle giovedì 6 dicembre 2007, Rado S ha scritto: I've an address for outgoing mail (with my provider's domain) and a local one ([EMAIL PROTECTED]). When I send local mail, in the header I fond always, as From field, the external address. There is a way to tell Mutt to use the external address only for outgoing emails and the internal one for local mail? I tried the following: send-hook '~t [EMAIL PROTECTED]' 'my_hdr From: Mutt User [EMAIL PROTECTED]' to send local email (the domain is debian) having [EMAIL PROTECTED] as sender, but it doesn't work. There is a misteke in format? Yes. When you use the ^ in your pattern, you're telling it to match the beginning of the address (the $ at the end tells it to match the end of the address). Thus [EMAIL PROTECTED] will ONLY match @debian and nothing else---it will not match [EMAIL PROTECTED], [EMAIL PROTECTED] or [EMAIL PROTECTED] either. ;) If you use this hook instead: send-hook '~t @debian$' 'my_hdr From: Mutt User [EMAIL PROTECTED]' ...then it WILL match all three examples I listed above, but will NOT match [EMAIL PROTECTED] (because the $ at the end is still there). Make sense? For more details, read up on regular expressions (Google should have plenty of info). ~Kyle - -- Come to me, son of Jor-El. Kneel before Zod. Snootchie-bootchies. -- Jay -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHWHATBkIOoMqOI14RArFdAJ0ek6TMAK3j0z0BuTXHtXHdZ4CuWwCfSbu7 vrcxV2l++TRrM1NI1hILibk= =tOEU -END PGP SIGNATURE-
Re: Reliable/safe way of removing empty maildirs?
On Thu, Dec 06, 2007 at 09:15:10PM +, A Darren Dunham wrote:
chmod a-w dir/new
if [ `find dir -type f` ] ; then
You have to do something like this instead:
[snip other responses]
Perhaps I've misunderstood the reason for doing this, but I would just
ask find to do a rmdir, and let it fail if the directory isn't empty.
find dir -depth -type d -exec rmdir {} \;
If 'dir' is still around when that finishes, it's probably because
there's a file in there now. In the meantime, it's removed all empty
subtrees.
... and left an *awful* mess, a maildir mailbox is a directory with
*three* sub-directories in it, you need to check that all three are
empty before removing them.
--
Chris Green
Re: locale and external address
Alle giovedì 6 dicembre 2007, Kyle Wheeler ha scritto: Yes. When you use the ^ in your pattern, you're telling it to match the beginning of the address (the $ at the end tells it to match the end of the address). Thus [EMAIL PROTECTED] will ONLY match @debian and nothing else---it will not match [EMAIL PROTECTED], [EMAIL PROTECTED] or [EMAIL PROTECTED] either. ;) If you use this hook instead: send-hook '~t @debian$' 'my_hdr From: Mutt User [EMAIL PROTECTED]' ...then it WILL match all three examples I listed above, but will NOT match [EMAIL PROTECTED] (because the $ at the end is still there). Make sense? It looks very resonnable, only that... I've still a trouble. I adopted the hook you suggested me. Now: in sent the headers look correct. The voice From is set just to samiel [EMAIL PROTECTED]. But when I controll in inbox after the delivering of email, I find again the old external address and not that one specified by the hook: samiel [EMAIL PROTECTED] I'm very confused, but I suspect that Exim rewrite the address furnished by Mutt with that one present in /etc/mail.addresses... Maybe, there is something to change in exim.conf too... M. -- linux user no.: 353546 public key at http://keyserver.linux.it
Re: locale and external address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, December 6 at 11:35 PM, quoth Mauro Sacchetto: If you use this hook instead: send-hook '~t @debian$' 'my_hdr From: Mutt User [EMAIL PROTECTED]' ...then it WILL match all three examples I listed above, but will NOT match [EMAIL PROTECTED] (because the $ at the end is still there). Make sense? It looks very resonnable, only that... I've still a trouble. I adopted the hook you suggested me. Now: in sent the headers look correct. Good! But when I controll in inbox after the delivering of email, When you control in inbox? I don't understand what you're talking about. I find again the old external address and not that one specified by the hook: samiel [EMAIL PROTECTED] I'm very confused, but I suspect that Exim rewrite the address furnished by Mutt with that one present in /etc/mail.addresses... Maybe, there is something to change in exim.conf too... M. Possibly. If your sent messages are correct, then your suspicion sounds plausible. ~Kyle - -- You can get more with a kind word and a gun than you can with a kind word alone. -- Al Capone -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHWH0GBkIOoMqOI14RAmsqAJ9XSrB2IDrtFXdGKid0qMDF4pKW5wCgmlSw 26z7kC93JoGkrH08vnAJdhU= =ooci -END PGP SIGNATURE-
Re: Mixmaster
On Thu, Dec 06, 2007 at 09:51:44PM +0100, Francesco Ciattaglia wrote: * Brian Salter-Duke [EMAIL PROTECTED] [06.12.07 21:31]: Is anyone using the mixmaster support in mutt? I ask merely because I was involved in improving this about 7 years ago, and I'm curious. I have no intention of ever using it again. The support is for a very old version of Mixmaster and not for the more recent version 3 betas. Should Mixmaster support be kept? It is unlikely to carry on working even with the old mixmaster code (version 2.4 beta 46 from September 2002), and that code may soon be not available. Brian. * Ci? letto, correndo gioved? 06 dicembre 2007, alle 21 e 38 rispondo cos?: Last Mixmaster changes are dated 2007 september, see: http://svn.noreply.org/svn/mixmaster/trunk/Mix/HISTORY Yes, but none of those versions (2.9 3.0) are supported as far as I know by thye current mutt code. About 7 years ago I looked at getting mutt to support the 2.9 version 3 betas and decided it was a really big job and beyond me. I have no intention of coming back to this. Are you going to do it? I would like to use mixmaster support, yes. I wrote also a complete reference guide* for using mixmaster with Mutt, but it's kept in stand-by, because of incompatibility between recent versions of Mutt and Mixmaster. Why not put it on the wiki? It might encourage people to remove the incompatability. I added a small change to update the manual to mutt.dev yesterday. It's an ideal argument for a flame war... anonimity: good or bad? Indeed and I do not want to go there. It is now not for me, so I am not going to touch the code. I have raised this, as I have said, just out of curiousity since I was active with mutt and mixmaster 7 years ago. IMHO it's good in some situations. In the country where I live, others are the instruments to protect yourself from abuse, crimes, ecc.. So I like Mixmaster as matter of study, in some sense. In other countries, perhaps, anonimity could be matter of life. * in italian and as a part of Il Nirvana con Mutt (see website in sig). ciao Ataualpa aka Francesco Ciattaglia. -- - Linux is better: Open Free! || www.ataualpa.altervista.org Brian. -- If a thing's worth doing, it is worth doing badly. -- G.K. Chesterton Brian Salter-Duke (Brian Duke) Email: b_duke(AT)bigpond(DOT)net(DOT)au
Re: locale and external address
Alle giovedì 6 dicembre 2007, Kyle Wheeler ha scritto: But when I controll in inbox after the delivering of email, When you control in inbox? I don't understand what you're talking about. I mean that, after receiving the email, it stays in inbox. In the header of this (seceived) mail, i find a changed field from, still with the external address and not with that one present in the original email. Who or what does change it? So, I think it's exim... M. -- Prof. Mauro Sacchetto Santa Croce 1332a 30135 Venezia tel.: 041 5226494 cell.: 320 7414579 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] linux user no.: 353546 public key at http://keyserver.linux.it
Re: Reliable/safe way of removing empty maildirs?
I needed to empty some subdirectories and this is what I did:
du test
4 test/cur
4 test/tmp
4 test/new
16 test
Nothing in the test directory, so I deleted it.
On Thu, Dec 06, 2007 at 10:28:26PM +, Chris G wrote:
On Thu, Dec 06, 2007 at 09:15:10PM +, A Darren Dunham wrote:
chmod a-w dir/new
if [ `find dir -type f` ] ; then
You have to do something like this instead:
[snip other responses]
Perhaps I've misunderstood the reason for doing this, but I would just
ask find to do a rmdir, and let it fail if the directory isn't empty.
find dir -depth -type d -exec rmdir {} \;
If 'dir' is still around when that finishes, it's probably because
there's a file in there now. In the meantime, it's removed all empty
subtrees.
... and left an *awful* mess, a maildir mailbox is a directory with
*three* sub-directories in it, you need to check that all three are
empty before removing them.
--
Chris Green
Re: Reliable/safe way of removing empty maildirs?
On 06Dec2007 21:15, A Darren Dunham [EMAIL PROTECTED] wrote:
| chmod a-w dir/new
| if [ `find dir -type f` ] ; then
|
| You have to do something like this instead:
| [snip other responses]
|
| Perhaps I've misunderstood the reason for doing this, but I would just
| ask find to do a rmdir, and let it fail if the directory isn't empty.
|
| find dir -depth -type d -exec rmdir {} \;
|
| If 'dir' is still around when that finishes, it's probably because
| there's a file in there now. In the meantime, it's removed all empty
| subtrees.
Yeah, but without even invoking find:
rmdir dir/new dir/tmp dir/cur dir \
|| mkdir -p dir/new dir/tmp dir/cur
Robust, safe, trivial.
People always seem to forget that rmdir is perfectly safe, in that it
won't remove empty directories.
Cheers,
--
Cameron Simpson [EMAIL PROTECTED] DoD#743
http://www.cskk.ezoshosting.com/cs/
Thousands at his bidding speed,
And post o'er land and ocean without rest - Milton
Re: Reliable/safe way of removing empty maildirs?
Cameron Simpson wrote: Yeah, but without even invoking find: rmdir dir/new dir/tmp dir/cur dir \ || mkdir -p dir/new dir/tmp dir/cur Robust, safe, trivial. Hooray for simplicity. :) People always seem to forget that rmdir is perfectly safe, in that it won't remove empty directories. I'm sure you meant just the opposite. It won't remove non-empty dirs. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ That men do not learn very much from the lessons of history is the most important of all the lessons of history. -- Aldous Huxley Collected Essays, 1959 pgp0zq36D0iq5.pgp Description: PGP signature
