Re: process substitution (was: Re: Searching big gobs of e-mail)
On Mon, Dec 17, 2001 at 07:12:32PM +0100, Gregor Zattler wrote: Hi Peter, Hi Gregor, hi mutt users, [...] mutt -f (grepmail -h cco@ *) i see mutt reading messages from /dev/fd/63, a few messages from grepmaiol and then: the mutt index which first looks fine but when I hit enter to read a message the pager was empty... Sorry, I seem to have properly tested it with zsh only. I assumed that bash does it the same way (create a temp file), and changed the =( syntax to ( for my posting. Thanks Christian and Vineet for the recherche. Peter -- VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
Re: process substitution (was: Re: Searching big gobs of e-mail)
* Gregor Zattler ([EMAIL PROTECTED]) [011218 03:44]: Hi Peter, hi mutt users, * Peter Poeml [EMAIL PROTECTED] [Mon 10 Dez 2001 20:04:17 GMT]: [...] As mentioned before, grepmail can jump in because mutt works on single mail boxes. Now I was curious and figured out the command for your real example: mutt -f (grepmail -huqd between 2001-09-01 and 2001-10-01 \ ^From.*frob@(foo|bar).net mbox1 mbox2 mbox3) This seems cool but when i gave it a (much more simppler) try: mutt -f (grepmail -h cco@ *) i see mutt reading messages from /dev/fd/63, a few messages from grepmaiol and then: the mutt index which first looks fine but when I hit enter to read a message the pager was empty... also ae (ls) emacs (ls) jed (ls) did not work. Any hints? Well, it won't help the bash-users out there, but anyone willing to give zsh a try will benefit from this excerpt from the Process substitution of the zshexpn manpage: Both the /dev/fd and the named pipe implementation have drawbacks. In the former case, some programmes may automatically close the file descriptor in question before examining the file on the command line, particularly if this is necessary for security reasons such as when the pro gramme is running setuid. In the second case, if the programme does not actually open the file, the subshell attempting to read from or write to the pipe will (in a typical implementa tion, different operating systems may have different behaviour) block for ever and have to be killed explicitly. In both cases, the shell actually supplies the information using a pipe, so that programmes that expect to lseek (see lseek(2)) on the file will not work. ... If = is used, then the file passed as an argument will be the name of a temporary file contain ing the output of the list process. This may be used instead of the form for a program that expects to lseek (see lseek(2)) on the input file. So this works for me: mutt -f =(mboxgrep -mmaildir '^From:.*callahan@homicide\.SFPD\.gov' $MAIL) mboxgrep even adds the wicked ^From_ lines! Really, though, zsh effectively does the same thing as what grepm does, with the temp file. Vineet -- Satan laughs when # I disapprove of what you say, but I will we kill each other.# defend to the death your right to say it. Peace is the only way. # --Beatrice Hall, The Friends of Voltaire, 1906 msg21763/pgp0.pgp Description: PGP signature
process substitution (was: Re: Searching big gobs of e-mail)
Hi Peter, hi mutt users, * Peter Poeml [EMAIL PROTECTED] [Mon 10 Dez 2001 20:04:17 GMT]: [...] As mentioned before, grepmail can jump in because mutt works on single mail boxes. Now I was curious and figured out the command for your real example: mutt -f (grepmail -huqd between 2001-09-01 and 2001-10-01 \ ^From.*frob@(foo|bar).net mbox1 mbox2 mbox3) This seems cool but when i gave it a (much more simppler) try: mutt -f (grepmail -h cco@ *) i see mutt reading messages from /dev/fd/63, a few messages from grepmaiol and then: the mutt index which first looks fine but when I hit enter to read a message the pager was empty... also ae (ls) emacs (ls) jed (ls) did not work. Any hints? Ciao, Gregor P.S.: The problem the thread was involved with (searching on multiple mailboxes) can be easily solved with a shell script called grepm. It simply redirects grepmails output in a temorary file, starts mutt with this and deletes the temorary file when mutt is exited.
Re: process substitution (was: Re: Searching big gobs of e-mail)
Hello searchers in Mutt,
On Mon, Dec 17, 2001 at 07:12:32PM +0100, Gregor Zattler wrote:
mutt -f (grepmail -h cco@ *)
i see mutt reading messages from /dev/fd/63, a few messages from
grepmaiol and then:
the mutt index which first looks fine but when I hit enter to read a
message the pager was empty...
Oops. I get the same result. Thinking about it, this is not
surprising. The process substitution construct creates a pipe to
avoid temporary files. If you want to access a message listed in the
index, you need random access to the mail box, which is something a
pipe does not give you.
So it's better to say something like eg,
grepmail -hm cco@ * /tmp/grpfldr ; mutt -f /tmp/grpfldr ; rm /tmp/grpfldr
And this is just what grepm does. People not using mbox format will
have to use mboxgrep (mentioned earlier in this thread).
ae (ls)
emacs (ls)
jed (ls)
Emacs cannot read from a pipe (at least not from the command line).
By the way: The pro searcher will create an index (in the sense of a
hash table) for his mail -- like real search engines and databases do.
Now I remember a tool called ``Managing Gigabytes'' which is often
used for searching in really big gobs of mail. You can find it there:
http://www.cs.mu.oz.au/mg/
Cheers,
Cristian
--
}{ Cristian Pietsch
}{ http://www.interling.de
msg21713/pgp0.pgp
Description: PGP signature
