From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25192 invoked by alias); 26 Oct 2011 23:09:02 -0000 Received: (qmail 25176 invoked by uid 22791); 26 Oct 2011 23:09:00 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-galgo.atl.sa.earthlink.net (HELO elasmtp-galgo.atl.sa.earthlink.net) (209.86.89.61) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Oct 2011 23:08:46 +0000 Received: from [70.170.59.51] (helo=macbook2.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RJCaU-0003ay-4I for gdb-patches@sourceware.org; Wed, 26 Oct 2011 19:08:46 -0400 Message-ID: <4EA892F4.3000302@earthlink.net> Date: Thu, 27 Oct 2011 00:24:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [PATCH] Add the "-info-os" command to MI References: <4E970915.8000207@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da9407ac1f53dda0c87caefb750dc60f27d63350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00713.txt.bz2 On 10/21/11 1:39 PM, Tom Tromey wrote: >>>>>> ">" == Kwok Cheung Yeung writes: >>> + { "info-os", { "info os", 1 }, NULL }, > I'd prefer a new function specific to MI to do the command-line parsing. > > I think this approach should be deprecated and that no new instances go > into the tree. They unnecessarily link MI to the CLI, making it harder > to change the CLI. > I can see the appeal of the decoupling, but we share argument parsing like this because there's not a lot of practical purpose to having two parsers - once the command is out there and being used, we're loath to change it much anyway. To me, the MI's main value is in avoiding cases where CLI ambiguity and elision makes for a better user experience, but in this case the arguments are data-driven by platform-specific code, not much ambiguity involved. Stan