headers
Thomas Glanzmann | 4 Jul 2005 12:23
Picon
Picon

Is there a patch which matches messages having an attachment?

Hello,
I am looking for a patch which allows me to limit a mailbox view with
patterns to messages having an attachment?

	Thomas
Permalink | Reply | 2 comments |
headers
René Clerc | 4 Jul 2005 12:40
Picon

Re: Is there a patch which matches messages having an attachment?

Hi Thomas,

* Thomas Glanzmann <sithglan <at> stud.uni-erlangen.de> [04-07-2005 12:23]:

> I am looking for a patch which allows me to limit a mailbox view with
> patterns to messages having an attachment?

David Champion's attachment counting patch does that.  See his post to
this list with M-Id:  <20050224015813.GC19055 <at> monkey.uchicago.edu>

The ~X <number> pattern does what you want.

HTH,

--

-- 
René Clerc                      - (rene <at> clerc.nl) - PGP: 0x9ACE0AC7

God is science's putty.
-René Clerc
Permalink | Reply | 1 comment |
headers
Thomas Glanzmann | 4 Jul 2005 12:53
Picon
Picon

Re: Is there a patch which matches messages having an attachment?

Hi René,

> David Champion's attachment counting patch does that.  See his post to
> this list with M-Id:  <20050224015813.GC19055 <at> monkey.uchicago.edu>

> The ~X <number> pattern does what you want.

thanks. Exactly what I was looking for.

	Thomas
Permalink | Reply | 0 comments |
headers
rns.mutt.20.semba | 6 Jul 2005 20:01
Favicon

FIX: Error compiling: no member named 'open64'

Hi,

I just downloaded mutt from CVS and tried to compile on a Sun Solaris system.

roshan <at> radon $ uname -a
SunOS radon 5.8 Generic_117350-23 sun4u sparc SUNW,Sun-Fire-480R

After successfully configuring, running 'make' results in the following error:

hcache.c: In function `mutt_hcache_open':
hcache.c:808: structure has no member named `open64'
hcache.c:829: structure has no member named `open64'
hcache.c: In function `mutt_hcache_close':
hcache.c:847: warning: unused variable `ret'
make[2]: *** [hcache.o] Error 1
make[2]: Leaving directory `/home/pg/roshan/downloads/mutt-cvs-2005-07-06'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/pg/roshan/downloads/mutt-cvs-2005-07-06'
make: *** [all] Error 2

Changing hcache.c to use "sys/fcntl.h" instead of "fcntl.h" corrected 
the error.

32c32
< #include <fcntl.h>
---
 > #include <sys/fcntl.h>

Building on x86 Linux with a 2.6 kernel is unaffected by this change.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Thomas Glanzmann | 6 Jul 2005 20:43
Picon
Picon

Re: FIX: Error compiling: no member named 'open64'

Hello,

> > hcache.c:808: ret = h->env->open(h->env, NULL, DB_INIT_MPOOL | DB_CREATE | DB_PRIVATE, 0600);

> hcache.c: In function `mutt_hcache_open':
> hcache.c:808: structure has no member named `open64'

this sounds more like a preprocessor bug in gcc. I can compile mutt
including hcache perfectly on a SunFire 280R running Solaris 8 with
SUNWspro (forte8).

	export LD_OPTIONS="-R/opt/csw/lib -L/opt/csw/lib -R/opt/csw/bdb4/lib -L/opt/csw/bdb4/lib"
	export PATH="/opt/forte8/SUNWspro/bin:/usr/ccs/bin:/usr/bin:/usr/openwin/bin:/opt/csw/bin"
	export CPPFLAGS="-I/opt/csw/include"
	export CC=cc
	export CFLAGS='-O'
	cd mutt-1.5.720050202
	./prepare --enable-hcache --enable-imap --enable-pop --with-slang=/opt/csw --with-ssl=/opt/csw
--prefix=/opt/csw --mandir=/opt/csw/share/man --with-docdir=/opt/csw/share/doc/mutt --with-idn=no
	gmake
	gmake DESTDIR=/opt/build/thomas/mutt-1.5.720050202-buildroot install
	# mmdf.5 is already packaged in tin and Debian hasn't it in either --tg 02:50 04-10-07
	rm /opt/build/thomas/mutt-1.5.720050202-buildroot/opt/csw/share/man/man5/mmdf.5

	Thomas
Permalink | Reply | 9 comments |
headers
Brendan Cully | 6 Jul 2005 20:55
Gravatar

Re: FIX: Error compiling: no member named 'open64'

On Wednesday, 06 July 2005 at 20:43, Thomas Glanzmann wrote:
> Hello,
> 
> > > hcache.c:808: ret = h->env->open(h->env, NULL, DB_INIT_MPOOL | DB_CREATE | DB_PRIVATE, 0600);
> 

Haven't we seen this bug before in the sasl and socket routines? I
remember being surprised that it hadn't bit the db code. I think
something like the following was supposed to work:

(h->env->open)(...)
Permalink | Reply | 8 comments |
headers
Thomas Glanzmann | 6 Jul 2005 21:05
Picon
Picon

Re: FIX: Error compiling: no member named 'open64'

Hello,

> Haven't we seen this bug before in the sasl and socket routines? I
> remember being surprised that it hadn't bit the db code. I think
> something like the following was supposed to work:

yes we did. And I understand now, why it never triggered before: It only
happens if you compile header cache with db4 support. For gdbm and qdbm
(not upstream yet) there is no such thing as ->open ...

> (h->env->open)(...)

I guess. :-)

	Thomas
Permalink | Reply | 0 comments |
headers
Thomas Dickey | 6 Jul 2005 21:48
Picon

Re: FIX: Error compiling: no member named 'open64'

On Wed, 6 Jul 2005, Brendan Cully wrote:

> On Wednesday, 06 July 2005 at 20:43, Thomas Glanzmann wrote:
>> Hello,
>>
>>>> hcache.c:808: ret = h->env->open(h->env, NULL, DB_INIT_MPOOL | DB_CREATE | DB_PRIVATE, 0600);
>>
>
> Haven't we seen this bug before in the sasl and socket routines? I
> remember being surprised that it hadn't bit the db code. I think
> something like the following was supposed to work:
>
> (h->env->open)(...)
   h->env->(open)(...)

--

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Permalink | Reply | 6 comments |
headers
Brendan Cully | 6 Jul 2005 22:50
Gravatar

Re: FIX: Error compiling: no member named 'open64'

On Wednesday, 06 July 2005 at 15:48, Thomas Dickey wrote:
> On Wed, 6 Jul 2005, Brendan Cully wrote:
> 
> >On Wednesday, 06 July 2005 at 20:43, Thomas Glanzmann wrote:
> >>Hello,
> >>
> >>>>hcache.c:808: ret = h->env->open(h->env, NULL, DB_INIT_MPOOL | 
> >>>>DB_CREATE | DB_PRIVATE, 0600);
> >>
> >
> >Haven't we seen this bug before in the sasl and socket routines? I
> >remember being surprised that it hadn't bit the db code. I think
> >something like the following was supposed to work:
> >
> >(h->env->open)(...)
>   h->env->(open)(...)

Just out of curiosity, what's the advantage of the second form?
Permalink | Reply | 3 comments |
headers
Thomas Dickey | 7 Jul 2005 00:13
Picon

Re: FIX: Error compiling: no member named 'open64'

On Wed, 6 Jul 2005, Brendan Cully wrote:

>>> (h->env->open)(...)
>>   h->env->(open)(...)
>
> Just out of curiosity, what's the advantage of the second form?

Both keep left-parenthesis away from 'open', so there's no "open()",
but it's more obvious which symbol is being repaired.  After all,
it's also common to put pointer expressions in parentheses, and someone
might forget what the point of the change was and remove it during a
cleanup.

--

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Permalink | Reply | 2 comments |

Gmane