On Tue, Apr 15, 2008 at 07:34:47PM +0200, "Kim N. Lesmer" <[EMAIL PROTECTED]> was heard to say: > On Tue, 15 Apr 2008 07:13:30 -0700 > Daniel Burrows <[EMAIL PROTECTED]> wrote: > > Hi Daniel. > > > How many readers of this list are using "aptitude search" as a > > subcommand in a script? Will you be impacted by this change? Will > > anyone else be adversely impacted despite not using it in a script? > > I have always been annoyed with this exact problem, but I don't think > the solution you think about implementing (doing like apt-cache) is the > best way to go.
I'm not quite sure what you mean by "like apt-cache". I'm thinking of something a bit more ambitious than just extending the search to descriptions; e.g., Enrico Zini has done some interesting work in this area that I'd like to incorporate or emulate. > From FreeBSD: > $ make search name=foo > > Aptitude: > $ aptitude search foo This would be like $ aptitude search '~nfoo' , right? > Anyway, just a thought. Users can already build up arbitrarily [0] complex queries if they know the aptitude search language. The question is, what should "aptitude search blah" do if the user hasn't provided any context about what sort of a search to do? I don't think that erroring out is the right thing to do; I think there should be a "default" search mode. The only reason this comes up as an issue is that the old default happens to have a very precise meaning that could conceivably have been useful in scripts that ask for, e.g., "linux-image-2\.6\..*" instead of "~nlinux-image-2\.6\..*". If the default had been "search names and descriptions" to start with, I wouldn't be so concerned, because that's clearly an interactive feature and not useful for scripts. Daniel [0] for some values of arbitrary; the aptitude search language has not grown general, or even primitive, recursion operators, and I don't have any reason to expect that it will. Anything that complicated should probably be done in a real programming language (e.g., python with python-apt) anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]