Re: How to restore my mail?
Kyle [20.Mär.2009 03:03]:
BUT when you booted your machine, your operating system automatically
deleted the contents of /tmp. This is considered a security feature,
as well as simply good housekeeping. IF you had $TMP or $tmpdir
pointed elsewhere, such as ~/.tmp/ or something similar, then your
mail will still be there, in a file beginning with "mutt-". IF your
editor keeps draft files somewhere other than the same directory as
the file being edited (i.e. someplace that wasn't in /tmp), you may be
able to recover it that way too.
Don't forget /var/temp, althought that might just be a smylink to /tmp
(I am not that familiar with Debian).
Unless you specify a different temp-name, as Kyle said, try using
something like
grep -r mutt- /{var,tmp,home}
JP
--
Time flies like the wind, but fruit flies like bananas.
accidently viewing attachments repeatedly
Dear Mutt users, when viewing attachments in external programs (notably openoffice), I often have a terminal sit "unused" for a while as I'm reading the attachment. What happens often is that I hit a key or enter in that terminal (which is showing just the last "$ mutt" command line). After closing the external program, mutt will then pick up the "enter" key that was pressed, and open the attachment again. And again, and again, until all accidently pressed enters have been processed. The same can happen while editing a message in an external emacs window. In this case it will just view the message text in mutt after you're done editing, which is much less annoying. Is there a way to have mutt flush the keyboard buffer directly after returning from an external program, either attachment viewer or editor? I can't think of any situations where you would actually _want_ such keypresses to be remembered, but I'm sure there are some. Regards, Hein Zelle -- Unix is user friendly. It's just very particular about who it's friends are. Hein Zelle h...@icce.rug.nl http://www.icce.rug.nl/~hein
Re: How to restore my mail?
On 2009-03-19 21:03, Kyle Wheeler wrote: > You *might* be able to restore it, *if* you use an alternate temp > directory (i.e. if you set the $TMP environment variable, or the > $tmpdir muttrc configuration setting, or maybe if your editor keeps > draft files in a nonstandard place). Thanks. I have not set the TMP variable, so the draft file was /tmp/mutt and has been deleted on boot. Bad luck, I have now set 'tmpdir=~/.mutt/'. Btw, is there a variable to tell mutt not to delete mails from the postponed mailbox on editing?
Re: Mutt crashing on exit or replying (sometimes)
Hi, * Joshua Tinnin wrote: On Wed, Mar 11, 2009 at 11:18:30AM -0500, Kyle Wheeler wrote: On Wednesday, March 11 at 10:36 AM, quoth Joshua Tinnin: >Program received signal SIGSEGV, Segmentation fault. >0x080cb71f in safe_strdup () >(gdb) backtrace >#0 0x080cb71f in safe_strdup () >#1 0x080b4d6a in rfc822_cpy_adr_real () >#2 0x080bc09c in mutt_default_from () >#3 0x080bc9d0 in ci_send_message () >#4 0x080a20d4 in mutt_pager () >#5 0x0805d753 in mutt_display_message () >#6 0x0806c3c3 in mutt_index_menu () >#7 0x0808c6e5 in main () >(gdb) That shouldn't happen. If it happens next time, please print the values of p->personal and p->mailbox after going up to rfc822_cpy_adr_real. If you have exact address enabled (please include mutt -v | grep EXACT), please also print p->val. Program received signal SIGSEGV, Segmentation fault. 0x28587029 in free () from /lib/libc.so.7 (gdb) backtrace #0 0x28587029 in free () from /lib/libc.so.7 #1 0x080cb622 in safe_free () #2 0x080b3648 in rfc822_free_address () #3 0x08076965 in mutt_free_opt () #4 0x080769e2 in mutt_free_opts () #5 0x0808c704 in main () (gdb) Can you please go up to rfc822_free_address() and print t->val (if exact address enabled), t->personal and t->mailbox. And then go up to mutt_free_opt() and print *p to see which address-related option is causing the trouble (maybe even in both cases). I suspect that one of these is corrupt as safe_strdup() and safe_free() both handle NULL pointers just fine. If that's true, we need to only find out why. Rocco
Re: what is the benefit of imap? Another meta-question.
Hi,
* David Champion wrote:
[ POP3 needs locking ]
That's implementation-dependent though. A server might require locking,
but it's not inherent to the protocol and it's possible to implement
one that has few of the contstraints that people have mentioned in this
thread.
RfC1939 explicitely states that the maildrop ("mailbox") needs to be
locked once a client is authenticated, see section 4. It doesn't say
what exactly the lock means, though. At least I read it like that.
Rocco
Re: How to restore my mail?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, March 20 at 12:03 PM, quoth W. Martin Borgert: > On 2009-03-19 21:03, Kyle Wheeler wrote: >> You *might* be able to restore it, *if* you use an alternate temp >> directory (i.e. if you set the $TMP environment variable, or the >> $tmpdir muttrc configuration setting, or maybe if your editor keeps >> draft files in a nonstandard place). > > Thanks. I have not set the TMP variable, so the draft file was > /tmp/mutt and has been deleted > on boot. Bad luck, I have now set 'tmpdir=~/.mutt/'. Ouch. Yeah, that's rough, but that will help in the future. > Btw, is there a variable to tell mutt not to delete mails from the > postponed mailbox on editing? Not that I know of. ~Kyle - -- They think I'm crazy, and maybe I am. But maybe I'm a genius. -- Mel Gibson -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAknDoIMACgkQBkIOoMqOI15K8wCgx6uDQP/A41Lc2pF3tUnyRhMc qjcAniBSCmS3t/7nQKhuKCia4VtGC8sL =QK8J -END PGP SIGNATURE-
Re: what is the benefit of imap? Another meta-question.
> RfC1939 explicitely states that the maildrop ("mailbox") needs to be
> locked once a client is authenticated, see section 4. It doesn't say
> what exactly the lock means, though. At least I read it like that.
This is drifting pretty far away from mutt, and I doubt any of us are
writing new POP client code, so I'll keep this shortish. :) I imagine
that I understand why the draft suggests a mailbox lock, but I think
it's wrong to interpret that as a real requirement of POP. RFC 1939
predates BCP-14 (RFC 2119) and no MUST/SHOULD is present. Absent such
terminology (and reasons for using it) I think that a protocol RFC
doesn't get to prescribe the exact behavior of the server as long as the
interface goals are met, and this can be done without an exclusive lock
on the whole mailbox. What 1939 describes may be necessary for some
server implementations, but not for all.
--
-D.d...@uchicago.eduNSITUniversity of Chicago
Just to clear the deck, I own no monkeys.
Re: what is the benefit of imap?
On Thu, Mar 19, 2009 at 12:34:18PM +0100, Rocco Rutte wrote: > Hi, > > * Chris G wrote: > >> On >> the other hand if you *don't* need to access mail from anywhere then >> IMAP is slower than other ways of doing it and doesn't add any other >> particular advantages. > > Depends. Most people using IMAP use it through IMAP providers which > "guarantee" you 24/7 availability. You mostly have professional admins > who do the work for you and ensure you have access to mail. With local > management, that would be your job. For example, your harddisk with the > mail spool dies and all mail is gone. That is rather unlikely to happen > with say gmail. > There's absolutely nothing that prevents you using, for example, fetchmail to get your mail from an IMAP server to a local repository of some sort. You then have the security of the remote IMAP management and the speed of local mail. I suppose you could argue that this is what off-line IMAP does but, as far as I know, there are *very* few good MUA implementations of off-line IMAP. -- Chris Green
Re: accidently viewing attachments repeatedly
On 2009-03-20, Hein Zelle wrote: > Dear Mutt users, > > when viewing attachments in external programs (notably openoffice), I > often have a terminal sit "unused" for a while as I'm reading the > attachment. What happens often is that I hit a key or enter in that > terminal (which is showing just the last "$ mutt" command line). > > After closing the external program, mutt will then pick up the "enter" > key that was pressed, and open the attachment again. And again, and > again, until all accidently pressed enters have been processed. The > same can happen while editing a message in an external emacs window. > In this case it will just view the message text in mutt after you're > done editing, which is much less annoying. > > Is there a way to have mutt flush the keyboard buffer directly after > returning from an external program, either attachment viewer or > editor? I can't think of any situations where you would actually > _want_ such keypresses to be remembered, but I'm sure there are some. I can think of a couple of ways to handle this. For the case of viewing attachments, you can put the attachment viewer in the background so that mutt immediately resumes running a taking input from the keyboard. If you're concerned about typing the wrong thing into that window, you can move the cursor or change menus so that an inadvertent enter won't do anything destructive or time-consuming. You can find more about running viewers in the background here: http://www.spocom.com/users/gjohnson/mutt/#background You can't very well do that with emacs, though, since you want mutt to wait until you're done editing. For that case, you might try setting your editor variable to this or to a script that implements something like this: gvim -f; while read -t1; do continue; done I'm using gvim for concreteness and so that I could test it; I don't have ready access to emacs. Not all shells support the -t option to read. Bash and some versions of ksh do. That command consumes any keys typed into the terminal while the editor is running and for 1 second after the editor terminates. There's no need, in principle, for the 1-second timeout, but I couldn't find a way to set the timeout to 0 using bash. That approach will work for the attachment viewer problem as well, but I think putting the viewer in the background is a better solution. HTH, Gary
Re: Mutt crashing on exit or replying (sometimes)
On 06Mar2009 15:44, Kyle Wheeler wrote: | Step 1 of establishing a UTF-8 environment is getting a terminal | program that supports it. Most of them do these days, but you need to | run them with the right flags. For example, xterm supports UTF-8, but | requires a bunch of flags to enable it, so they usually provide the | `uxterm` script in order to launch xterm in UTF-8 mode. The rxvt | terminal has a similar script (I think it's `urxvt`). Aside: the "urxvt" command is usually the rxvt-unicode terminal emulator, a fork of the rxvt sources, much embellished. Unless there is _also_ a "urxvt" script associated with rxvt, but I've never seen them conflict... -- Cameron Simpson DoD#743
Re: Mutt crashing on exit or replying (sometimes)
On 08Mar2009 23:07, Kyle Wheeler wrote: | On Friday, March 6 at 08:18 PM, quoth John J. Foster: | >Hey Kyle - I've only been running on a Mac since January (former | >Gentoo user). But I've not changed my environment, knowingly, to effect | >this and my locale shows: | | Huh - well, maybe it does get things right now. I've been using Macs | forever, and they didn't *used* to set the right locale. I admit I | haven't re-checked recently. But if they've started, that's excellent. I think they probably have. I've only been using Macs for a bit over a year. I have: [/Users/cameron]admins-macbook*> locale LANG="en_US.UTF-8" LC_COLLATE="C" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_AU.UTF-8" LC_MONETARY="en_AU.UTF-8" LC_NUMERIC="en_AU.UTF-8" LC_TIME="en_AU.UTF-8" LC_ALL= The LC_COLLATE is my own, to make listings go in the order I historicly expect (and on which I suspect some of my shell scripts rely). Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Ed Campbell's pointers for long trips: 6. *NEVER* trust anyone in a cage, if they weren't nuts they'd be on a bike like everyone else.
