On Wed, Apr 16, 2008 at 12:38:46AM +0900, Osamu Aoki <[EMAIL PROTECTED]> was heard to say: > On Tue, Apr 15, 2008 at 07:13:30AM -0700, Daniel Burrows wrote: > > Hello list, > > > > I'd like to get a feel for how people use "aptitude search". > > > > # Background # > > > > One of the things I'd like to implement in an upcoming aptitude > > release (probably post-lenny, likely next year) is a significant > > overhaul of the UI to the search engine; that is, how searches are > > entered and carried out from the interface. > > > > In the current CLI, "aptitude search blah" searches for packages > > whose name contains "blah". In contrast, "apt-cache search blah" > > searches both package names and descriptions. What I'd really like to > > do is a full-text search with approximate matches on the whole package > > index that returns packages which might be relevant to "blah", with an > > option to sort the results by various relevance metrics. Of course, > > "aptitude search ?name(blah)" will always be available; this is just > > about changing the default behavior on bare strings. > > Changing default behavior on bare strings seems minor problem to me. > > I thought thare are 3 simple uses for old search patterns: > 1. aptitude search blah > 2. aptitude search ~nblah > 3. aptitude search ~dblah > > 1 and 2 are the same result now. > > If you want to make > aptitude search blah > acts as: > aptitude search "~nblah|~dblah" > > You need to tell in NEWS file that local scripts need to add "~n" before > serch string to make it act as before under the new version.
My question was: are there any such local scripts? It seems possible to me that someone might have written a script that uses aptitude this way, but I had trouble coming up with an actual reason I'd do that, especially since the output from "aptitude search" is notably bad for scripting. > "?name(blah)": is this your new syntax? Yes I see it now in manpage. > I do not like this one since "?" is used as metacharacter for regex in > ERE. Aptitude is extended ERE as I understand before you aded this. It still is. I picked "?" because it is (a) suggestive of starting a query word, (b) not ambiguous (all previous queries continue to have the same meaning), and (c) it has a minimum of syntactic overhead. Something like "~?name" is just obnoxious to type, although I could see adding it as an alternative to see how it works. As you noted below, there's a funny corner case when you mix the two styles of writing expressions, but it doesn't affect backwards compatibility. > The extension was "~". When did you add this? Why did not you chose > sequence like "~?name(blah)" as long expression. Then ? is clearly not > part of ERE expression. For example, "~ddpkg~ndpkg" is good pattern but > "~ddpkg?name(dpkg)" can not be parsed correctly. "~ddpkg?name(dpkg)" means what it used to: match the regex "dpkg?name(dpkg)" against the description field of packages. Terms introduced by a tilde character still consume text up to the next whitespace. This may be a bit surprising if you're used to the old syntax, but it's predictable once you get the rule (I note, though, that the documentation here needs to explicitly mention this). I feel this is an acceptable level of annoyance to put up with for backwards-compatibility. A more problematic example is "aptitude?installed", which is parsed as a single regex. Again, though, just putting a space between the terms makes everything work. > > # Problem # > > > > The problem that I see is that aptitude's current behavior is > > predictable enough that people might be relying on it in home-grown > > scripts. Changing the semantics of a command underneath a script is > > impolite at best and will likely break things. > > Impolite... maybe if you did not announce. But if you have that > announced for lenny, doing so for lenny+1 is fine. > > (Did you do that for new "?" syntax? Was this hidden feature?) I didn't see a need to announce in NEWS, since it was backwards-compatible. If you can find a case where it's not, that's a bug and needs to be fixed, but I'm pretty confident from the implementation that it's not. The new terms are only recognized in contexts where previous versions would have tried to parse a regex and failed. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
