Bug #44936 for Mail-IMAPClient: search method will escape parameter strings provided at the end of the list of arrays

Fri Apr 10 19:13:06 2009 whicuz [...] gmail.com - Ticket created

Subject:

search method will escape parameter strings provided at the end of the list of arrays

If you run a search with a list of valid parameters and do not terminate it in a search keyword, then there will be an error. The problem with this is that it makes it difficult to programatically create a list of search parameters. For example, if you are going to have a list of FROM "NAME" search constraints, the last one will have the already-escaped "NAME" element quoted. My work-around was to always append ALL to the list of array elements, but if you automatically escaped every array parameter that was not a method it would at least provide consistency. I do not have any code, but any simple list of terms with arguments where the last is not a keyword should demonstrate the inconsistency.

Sat Apr 11 14:32:54 2009 PLOBBES [...] cpan.org - Correspondence added

Agreed. The current code only escapes/quotes the final argument and the documentation is inconsistent with behavior. We'll see if I can get a patch in for the next release.

Sat Apr 11 14:32:55 2009 The RT System itself - Status changed from 'new' to 'open'

Sat Apr 25 00:33:44 2009 PLOBBES [...] cpan.org - Taken

Fri May 08 14:34:16 2009 PLOBBES [...] cpan.org - Correspondence added

In the next release of Mail::IMAPClient (3.17) I have changed search() behavior so that it will hopefully DWIM. Internally, I've added a _quote_search() method that will be called to quote the SEARCH command. This means you will not (or should not) need to quote things going into SEARCH if all works well. However, if you want total control then you can pass in SCALAR references for the data and they will pass through untouched. I'll close this with the expectation that this is the desired behavior, but if you end up testing and see problems please re-open or file a new bug, thanks! Here's the new code for quoting: sub _quote_search { my ($self, @args) = @_; my @ret; foreach my $v (@args) { if( ref($v) eq "SCALAR" ) { push( @ret, $$v ); } elsif( exists $SEARCH_KEYS{ uc($_) } ) { push( @ret, $v ); } else { push( @ret, $self->Quote($v) ); } } return @ret; }

Fri May 08 14:34:17 2009 PLOBBES [...] cpan.org - Status changed from 'open' to 'resolved'

Sat May 09 15:00:15 2009 whicuz [...] gmail.com - Correspondence added

Subject:	RE: [rt.cpan.org #44936] search method will escape parameter strings provided at the end of the list of arrays
Date:	Sat, 9 May 2009 14:59:54 -0400
To:	<bug-Mail-IMAPClient [...] rt.cpan.org>
From:	"Charles Justin Henck" <whicuz [...] gmail.com>

Thanks for your work! Show quoted text

-----Original Message----- From: Phil Lobbes via RT [mailto:bug-Mail-IMAPClient@rt.cpan.org] Sent: Friday, May 08, 2009 2:34 PM To: whicuz@gmail.com Cc: DJKERNEN__NO_SOLICITING__@cpan.org Subject: [rt.cpan.org #44936] search method will escape parameter strings provided at the end of the list of arrays <URL: https://rt.cpan.org/Ticket/Display.html?id=44936 > In the next release of Mail::IMAPClient (3.17) I have changed search() behavior so that it will hopefully DWIM. Internally, I've added a _quote_search() method that will be called to quote the SEARCH command. This means you will not (or should not) need to quote things going into SEARCH if all works well. However, if you want total control then you can pass in SCALAR references for the data and they will pass through untouched. I'll close this with the expectation that this is the desired behavior, but if you end up testing and see problems please re-open or file a new bug, thanks! Here's the new code for quoting: sub _quote_search { my ($self, @args) = @_; my @ret; foreach my $v (@args) { if( ref($v) eq "SCALAR" ) { push( @ret, $$v ); } elsif( exists $SEARCH_KEYS{ uc($_) } ) { push( @ret, $v ); } else { push( @ret, $self->Quote($v) ); } } return @ret; }

Sat May 09 15:00:16 2009 The RT System itself - Status changed from 'resolved' to 'open'

Thu May 21 11:06:08 2009 PLOBBES [...] cpan.org - Fixed in 3.17 added

Thu May 21 11:06:08 2009 PLOBBES [...] cpan.org - Correspondence added

3.17 is out with the fixes for this. Hopefully it is backwards compatible enough that it will not impact others upgrading to 3.17. It is hard to guess for sure as the behavior was not in line with documentation and existing test cases were already broken.

Thu May 21 11:06:11 2009 PLOBBES [...] cpan.org - Status changed from 'open' to 'resolved'