"port deps" failure on +

[contact1@…]

I've discovered that when one tries to find dependencies using "port deps", this command fails for the ports with "+" in the name. (I'm running on MacOS X 10.3.2).

For example, "port deps libxml++" gives the output:

port search failed: couldn't compile regular expression pattern: quantifier operand invalid

I don't know shell scripting enough to find the bug in the port script.

Also, if one does "port deps libxml+", one gets the result for "port deps libxml" rather than a warning related to the port not existing. This is probably part of the same issue.

-albert

[blb@…]

This is due to the portname given to port not being escaped before doing regex operations on it; until it is fixed, you can still make it work by doing

port deps libxml
+
+

[jmpp@…]

So, what's the word on this bug? Do we allow the + symbol in port names and go to the extents of adapting our search patterns to accept it... or do we make policy to avoid such character?

-jmpp

[blb@…]

* Bug 3167 has been marked as a duplicate of this bug. *

[pguyot (Paul Guyot)]

* Bug 4704 has been marked as a duplicate of this bug. *

[jberry@…]

I can no longer regress this bug for 1.2.

[jmpp@…]

We've made some good advances, + characters have usually needed double escaping to get them all the way through to port(1). But this is no longer the case:

$[juan@PowerBook(ttyp1): LogMap_Crypt](951/0,0)-> port deps libxml++ libxml++ has build dependencies on:

pkgconfig

libxml++ has library dependencies on:

libxml2

Woot! But woot'd too soon I did:

$[juan@PowerBook(ttyp1): LogMap_Crypt](953/0,0)-> port search libxml++ Error: /opt/local/bin/port: search for portname libxml++ failed: couldn't compile regular expression pattern: quantifier operand invalid

The search action takes its argument and tries to construct a regular expression with it on which to browse the index, so I guess the + character is still polluting this regexp. Unfortunately, netiher single nor double escaping help us in this particular case:

$[juan@PowerBook(ttyp1): LogMap_Crypt](955/1,0)-> port search libxml\+\+ Error: /opt/local/bin/port: search for portname libxml++ failed: couldn't compile regular expression pattern: quantifier operand invalid

$[juan@PowerBook(ttyp1): LogMap_Crypt](956/1,0)-> port search libxml
+
+ Error: /opt/local/bin/port: search for portname libxml++ failed: couldn't compile regular expression pattern: quantifier operand invalid So I guess there's still some cleaning needed here. I'm reopening the bug for the time being.

-jmpp

PS: All tests performed with HEAD tools, refreshed by a "cvs up" not more than a couple of minutes ago.

[blb@…]

Now the search workaround needs two escapes for DP (hence four total, since two are needed for the shell):

$ port search libxml

+

+ libxml++ textproc/libxml++ 1.0.2 libxml++ is a C++ interface for working with XML files libxml++2 textproc/libxml++2 2.10.0 libxml++ is a C++ interface for working with XML files

[jberry@…]

Your issue with search is a different bug, but...I'll play along. I check in a fix for the fact that we were losing a level of quoting.

For search, since it's using regex, you still need to quote the special regex characters, and protect them from the shell. But you shouldn't have to add a second layer of quoting (which I just fixed). So now the following does work:

port search 'libxml\+\+' libxml++ textproc/libxml++ 1.0.2 libxml++ is a C++ interface for working with XML files libxml++2 textproc/libxml++2 2.10.0 libxml++ is a C++ interface for working with XML files

This is what I would expect, and I don't know how to make it any better.