[Compressed-Folders] file descriptor leaking fixed
There were four file descriptor leaks in the old versions of the
compressed folders patch. The attached patch fixes this problem.
The patch can be applied after most versions of the compressed folders
patch it should work with 0.95.*, 0.96.* and 1.0pre*.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
--- compress.c.org Fri Sep 24 09:42:23 1999
+++ compress.c Wed Sep 29 10:06:53 1999
@@ -213,6 +213,7 @@
mutt_system(echo_cmd);
rc = mutt_system (cmd);
mx_unlock_file (ctx->realpath, fileno (fp), 1);
+ fclose (fp);
if (rc)
{
@@ -332,6 +333,7 @@
}
mx_unlock_file (ctx->realpath, fileno (fp), 1);
+ fclose (fp);
safe_free ((void **)&cmd);
@@ -403,10 +405,12 @@
ctx->path);
safe_free ((void **)&cmd);
mx_unlock_file (ctx->realpath, fileno (fp), 1);
+fclose (fp);
return (-1);
}
mx_unlock_file (ctx->realpath, fileno (fp), 1);
+ fclose (fp);
remove_file (ctx);
restore_path (ctx);
safe_free ((void **)&cmd);
PGP signature
Re: interactive options on mailcap
Brian - And on Sat, Sep 25, 1999 at 11:54:40AM +0930 it was said by Brian Salter-Duke: | This does exactly what you asked for and is much shorter than the one I | posted a while back. | | #!/usr/local/bin/perl | $file = $ARGV[0]; | $base = $file; | $base =~ s?\.gz??; | print "Type the directory name where you wish to save the file: "; | $dir = ; | chop($dir); | system "/usr/local/bin/gunzip $file"; | system "cp $base $dir"; | unlink $base; | | Cheers, Brian. Have finally looked at this (when a whole lot of zipped files came in by mail) and adjusted the script a bit as you may see below - I left the comments in just for show. The script does what I want, but will have to add stuff to handle tar.gz files as well. Also wanted to add some user feedback of the system command - but failed - did not try too hard (last two lines). A real bonus is that your system "command" allows interpretation of my env variables like $re = /usr/data/development/reports etc. But an unpatched mutt don't - major :( - (Would be great to have tab completion and other readline type functionality, I guess.) Thanks for your help: #!/usr/local/bin/perl #$file = $ARGV[0]; #$base = $file; #$base =~ s?\.gz??; #$base =~ s?\.zip??; #My gunzip did not seem to have an option for destination dir. print "Type the directory name where you wish to save the file: "; $dir = ; chop($dir); system "/usr/bin/unzip -d$dir $ARGV[0]"; #print "$!"; #print "Click anything to carry on"; #(<>); #system "cp $base $dir"; -- Eric Smith [EMAIL PROTECTED] Pass calmly through the clamour of the bungled.
send-hook execution order
Hi, according to the manual: Usage: send-hook [!]pattern command This command can be used to execute arbitrary configuration commands based upon recipients of the message. pattern is a regular expression matching the desired address. command is executed when regexp matches recipients of the message. When multiple matches occur, commands are ^ executed in the order they are specified in the muttrc. ^^ So, I tried the following: macro generic \e0 "!~/sigscript\r" send-hook '~C anyone@anyplace\.com' "push \e0" send-hook '~C anyone@anyplace\.com' "set signature=~/timeup.sig" sigscript is a script that calls the command `uptime` and copies it to file called timeup.sig. The problem here is that \e0 is executed only when I quit the message edition, so timeup.sig is not updated before being used as the signature file. If there's a better way to get this, I'd like to know, but would also like to know why these hooks are not running in the supposed order. TIA -- Horacio LC_mutt=es_ES mailto:[EMAIL PROTECTED]http://carlotha.ciberia.es/mutt/ ~ Spain ~ Spanje ~ Spanien
Re: send-hook execution order
J Horacio MG <[EMAIL PROTECTED]> wrote on Wed, 29 Sep 1999: > macro generic \e0 "!~/sigscript\r" > send-hook '~C anyone@anyplace\.com' "push \e0" > send-hook '~C anyone@anyplace\.com' "set signature=~/timeup.sig" > If there's a better way to get this, I'd like to know, but would also > like to know why these hooks are not running in the supposed order. First, "a better way": It's possible to set your signature to an output from a program, like set signature="randsig.sh .sig-body|" Which runs the command "randsig.sh .sigh-body" and uses the output from that as the signature. With a send-hook (like I use it), that would be: send-hook . 'set signature="randsig.sh .sig-body|"' So you can probably easily modify your sigscript to print to STDOUT instead of it changing timeup.sig, and then use something like: send-hook '~C anyone@anyplace\.com' "set signature=~/sigscript|" As for why the send-hooks aren't executed like you expect... Well, what happens is that send-hooks are evaluated after you have given the recipient address (when Mutt gives the To: and possibly the Cc: prompt) and subject, and right before the editor is started. At this point, if you "push" any keystrokes into the buffer, they end up queued until you exit from the message composition. From Mutt's point of view, you're still doing a single action -- sending mail -- and anything pushed will only execute until that's over. (Anyone who knows better than me is welcome to give a better explanation about this...) HTH, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs / What if there were no hypothetical situations?
delete to trash folder
Is there a simple way to configure mutt to move messages to a specific (trash) folder when the delete operation is called? This will allow me to recover deleted messages and purge the trash folder of very old messages via a cron job. -- John Benninghoff
there is new mail in ...
Hello, I am quite new with mutt, so please forgive me if the quetion is stupid. I have got two mailboxes =friends and =to_friends. If I change from the +friends mailbox to the other one the message 'New mail in =to_friends.' appears in the status-line though this is not true. If I then change back to =to_friends mutt tells me 'New mail in =friends.' though also not true. And so on ... What do i wrong ? (The folders reside on an NFS directory and mails are delivered in these folders with .procmail. The decribed efect is observable both in Mutt 1.0pre1i and Mutt 1.0pre3i). Many thanks in advance A. Dvorak
Re: there is new mail in ...
On Wed, 29 Sep 1999, Alexander Dvorak t2069 wrote: > I have got two mailboxes =friends and =to_friends. > If I change from the +friends mailbox to the other one > the message 'New mail in =to_friends.' appears in the > status-line though this is not true. If I then change > back to =to_friends mutt tells me 'New mail in =friends.' > though also not true. And so on ... > What do i wrong ? I've experienced the same problem when I used MH folders. Now that I've switched to Maildir I have no such problems. Also, on my home computer where I use mbox folders I have noticed the opposite effect, ie in the folder-index, folders are only marked 'N' if I haven't looked in them. If I have viewed a folder without reading any of the new mail I had in it, the 'N' mark goes away. I would recommend trying Maildir, as MH isn't really supported, and mbox doesn't tell you where you have unread mail. Of course, your problem might be of another origin. /Staffan
Re: delete to trash folder
John Benninghoff Linux" [[EMAIL PROTECTED]] wrote: > Is there a simple way to configure mutt to move messages to a specific (trash) > folder when the delete operation is called? This will allow me to recover > deleted messages and purge the trash folder of very old messages via a cron > job. The simplest hack is to use macros: macro index d "s=trash" macro pager d "s=trash" But this isn't perfect. I've seen a few patches floating around to add real trash support, perhaps you could find them in the list archives. -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- "If Microsoft can change and compete on quality, I've won." -- L. Torvalds PGP signature
Re: there is new mail in ...
Staffan Hämälä writes: > On Wed, 29 Sep 1999, Alexander Dvorak t2069 wrote: [...] Staffan's mail has a duplicate X-Mailer: Mutt 1.0pre3i header. A problem with that release? -- After a number of decimal places, nobody gives a damn.
Re: there is new mail in ...
On Wed, Sep 29, 1999 at 07:34:44PM +0100, Lars Hecking wrote: > Staffan Hämälä writes: > > On Wed, 29 Sep 1999, Alexander Dvorak t2069 wrote: > [...] > Staffan's mail has a duplicate > X-Mailer: Mutt 1.0pre3i > header. A problem with that release? I'm not seeing it on my mail and I'm using that release. Do you see duplicates on this message? > -- > After a number of decimal places, nobody gives a damn. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
Re: there is new mail in ...
> > Staffan's mail has a duplicate > > > X-Mailer: Mutt 1.0pre3i > > > header. A problem with that release? > > I'm not seeing it on my mail and I'm using that release. Do you > see duplicates on this message? Nope, yours is fine. The only other duplicate X-Mailer: in this month's mutt-users archive was marked Mutt 0.95.7i. So it may be a local/config problem.
Re: there is new mail in ...
Lars Hecking <[EMAIL PROTECTED]> wrote: > > The only other duplicate X-Mailer: in this month's mutt-users archive > was marked Mutt 0.95.7i. So it may be a local/config problem. There is a bug that causes the X-Mailer to be re-added to the headers, whenever a message is postponed and recalled. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: there is new mail in ...
Lars Hecking: > > > Staffan's mail has a duplicate > > > > > X-Mailer: Mutt 1.0pre3i > > > > > header. A problem with that release? > > > > I'm not seeing it on my mail and I'm using that release. Do you > > see duplicates on this message? > > Nope, yours is fine. > > The only other duplicate X-Mailer: in this month's mutt-users archive > was marked Mutt 0.95.7i. So it may be a local/config problem. I can get a duplicate X-Mailer header by editing a message that was sent with mutt and then resending it. I'll use this message as an example. Sending it to myself first ... I received it. Now I'm editing it and I'll send it again, to mutt-users, this time ...
Re: there is new mail in ...
Alexander Dvorak t2069 <[EMAIL PROTECTED]> wrote on Wed, 29 Sep 1999: > The folders reside on an NFS directory > and mails are delivered in these folders with > .procmail. Like others, I recommend switching to Maildir folders if you are reading your mail from NFS-mounted disk. Not that I've ever had any real trouble with mbox format folders over NFS, but I prefer using Maildir rather than having to find out the hard way how mbox folders can get corrupted... But with Maildirs too, I have a "problem" with new mail reporting. This only happens when I have new mail, and I don't want to update the N flags, so I press $ to sync the folder, then % to avoid writing changes on exit. After that, when I change to another folder, Mutt tells me that I have "New mail in =FolderIJustLeft". This is more of a minor annoyance than a problem. And for all I know, it's been "designed to work that way". However I'd prefer if Mutt would check if there *really* is new mail in the folder, not just mail that existed there already and which is still marked as new. Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs / Never forget: 2 + 2 = 5 for extremely large values of 2.
Re: there is new mail in ...
Mikko Hänninen <[EMAIL PROTECTED]> wrote: > > I don't want to update the N flags, so I press $ to sync the > folder, then % to avoid writing changes on exit. After that, when > I change to another folder, Mutt tells me that I have "New mail in > =FolderIJustLeft". This is more of a minor annoyance than a problem. > And for all I know, it's been "designed to work that way". However > I'd prefer if Mutt would check if there *really* is new mail in the > folder, not just mail that existed there already and which is still > marked as new. In maildir folders, mail with the "N" status is placed in the "new" subdir. And so are messages that have been newly delivered. So, Mutt can't tell the difference between these two types of messages. So when it switches away, it notices files in the "new" subdir, and tells you that there is new mail. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
"you have new mail in " - WHERE?!?
I am getting the same problem reported about mutt telling of new mail in mailboxes, but there is nothing there. I keeps on telling me that I have new mail in my spool folder and also in a regular maiulbox under ~/Mail. Every time I go to either there is nothing new there. This has been happening all day. What could be the problem here? This is all local mail, no NFS, and are regular mbox format. Thanks. -Ken -- [EMAIL PROTECTED]AIM: ScopusFest
Re: "you have new mail in " - WHERE?!?
Ken W <[EMAIL PROTECTED]> wrote: > > I am getting the same problem reported about mutt telling of new mail > in mailboxes, but there is nothing there. I keeps on telling me that > I have new mail in my spool folder and also in a regular maiulbox > under ~/Mail. Every time I go to either there is nothing new there. Mutt checks mbox folders by examing the time stamp information. Try these commands, when Mutt is reporting new mail: ls -l /path/to/spool/file (modified time) ls -lu /path/to/spool/file (accessed time) By comparing the time when the the folder was last changed, against the time when it was last read, Mutt makes its determination of whether the folder has new mail in it. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: "you have new mail in " - WHERE?!?
On Wed, Sep 29, 1999, David DeSimone wrote: > Mutt checks mbox folders by examing the time stamp information. > > Try these commands, when Mutt is reporting new mail: > > ls -l /path/to/spool/file(modified time) > ls -lu /path/to/spool/file(accessed time) > > By comparing the time when the the folder was last changed, against the > time when it was last read, Mutt makes its determination of whether the > folder has new mail in it. Thanks, David. The times were indeed different when I checked just now since it reported new mail again. It is only with my spool folder and one other under ~/Mail. What could this be since it is the same two mailboxes over and over again? -Ken -- [EMAIL PROTECTED]AIM: ScopusFest
Re: "you have new mail in " - WHERE?!?
Ken W <[EMAIL PROTECTED]> wrote: > > > ls -l /path/to/spool/file (modified time) > > ls -lu /path/to/spool/file (accessed time) > > Thanks, David. The times were indeed different when I checked just > now since it reported new mail again. Mutt should only report new mail if the "modified" time is later than the "accessed" time. > What could this be since it is the same two mailboxes over and over > again? I have heard a problem reported on this list before, that some MDA's leave the mailbox in such a state that the "modified" and "accessed" times end up EQUAL. Mutt is not sure what to make of this: Did the user read the folder at the same time it was changed? Probably not... So Mutt reports new mail in this case. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
[Announce] mutt-1.0pre3XX-x RPMs
Hi folks! Thanks to the help of four other mutt friends, RPMs for mutt-1.0pre3 are now available: Version | US | international ---+--+--- RHL 5.2/i386 | Y | Y RHL 5.2/sparc | Y | soon RHL 6.0/i386 | Y | soon RHL 6.0/sparc | soon | soon (1.0pre2i and us available) SuSE 6.2/i386 | Y | soon All RPMs come in plain and with compressed folder support. NOTE: There's only *one* SRPM for the international version and one for the US version as *all* other RPMs can be built from those SRPMs. Please refer to the RPMS.README for more info. They reside at the following locations: Mutt International Version -- URL: http://mutt.linuxatwork.at Mutt US Version --- URL: http://www.woodsoup.org/~emgaron/tuxior.hmtl All READMEs and file lists are available on the web pages, hence I decided not to attach them... Make sure to read them! Have fun, Thomas P.S.: Still wanted: Folks to build RPMs for other distros! -- - Thomas Ribbrockhttp://www.bigfoot.com/~kaytanICQ#: 15839919 "You have to live on the edge of reality - to make your dreams come true!"
Re: there is new mail in ...
David DeSimone <[EMAIL PROTECTED]> wrote on Wed, 29 Sep 1999: > In maildir folders, mail with the "N" status is placed in the "new" > subdir. And so are messages that have been newly delivered. Right, yes, understood. > So, Mutt > can't tell the difference between these two types of messages. So when > it switches away, it notices files in the "new" subdir, and tells you > that there is new mail. But it could, in theory, keep track of how many messages were in the "new" dir when it left that folder, and if that number is the same currently then there is no "really new" mail. Presumably if there would be new mail added to the folder, the number of files would increase. Of course, this is unreliable if some other MUA is used to read/handle mail in that same folder, it could move a message from the "new" dir to "cur" and a new message could just arrive, making the count match. But this scenario is rather improbable. And now that I think of it, Mutt could just check the modified time for the "new" folder to see the last change within that dir, couldn't it? Although that wouldn't tell whether there's new mail arrived, or mail in "new" moved/deleted. Anyway I don't know how much work this all would be implementing in practice, and the behaviour is just a minor irritant. A much bigger irritant is that in the folder index, if I have sort by "reverse-date", Mutt uses the actual main directory timestamp for Maildir folders. This never changes, so the order of Maildirs is always the same, regardless of whether there is new mail or not. Much more useful would be if Mutt would check the timestamp of the "new" directory inside the Maildir (and possibly the "cur" too, using the newer of the two) so that these folders would sort correctly. Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs / Money isn't everything. There's also roleplaying games.
bind r to reply with include=yes and R to reply with include=no
Hi, Is there a way to bind the following two keys to behave like this? bind r reply include = yes bind R reply include = no Thanks. Shao. -- Shao Zhang - Running Debian 2.1 ___ _ _ Department of Communications/ __| |_ __ _ ___ |_ / |_ __ _ _ _ __ _ University of New South Wales \__ \ ' \/ _` / _ \ / /| ' \/ _` | ' \/ _` | Sydney, Australia |___/_||_\__,_\___/ /___|_||_\__,_|_||_\__, | Email: [EMAIL PROTECTED] |___/ _
Re: bind r to reply with include=yes and R to reply with include=no
Shao Zhang <[EMAIL PROTECTED]> wrote on Thu, 30 Sep 1999: > bind r reply include = yes > bind R reply include = no Hmmm, something like: macro index r ":set include=yes\n" macro index R ":set include=no\n" I think? Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs / Q: How many surrealists does it take to change a light bulb? A: Fish
