From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26721 invoked by alias); 14 Feb 2006 20:59:35 -0000 Received: (qmail 26712 invoked by uid 22791); 14 Feb 2006 20:59:34 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Feb 2006 20:59:33 +0000 Received: from kahikatea.snap.net.nz (p202-124-114-247.snap.net.nz [202.124.114.247]) by viper.snap.net.nz (Postfix) with ESMTP id E6AA9742BDE; Wed, 15 Feb 2006 09:59:25 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id E81138890; Wed, 15 Feb 2006 09:58:24 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17394.17519.510199.853654@kahikatea.snap.net.nz> Date: Tue, 14 Feb 2006 20:59:00 -0000 To: "Bjarke Viksoe" Cc: gdb@sourceware.org Subject: RE: MI error msgs and localization In-Reply-To: References: <17393.12925.270558.512941@kahikatea.snap.net.nz> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00145.txt.bz2 > >I would guess that most of time GDB is used from the command line where > >there is simply no front-end, dumb or otherwise. > > But we are talking about MI mode now and how that should be shaped? Perhaps we are not communicating but you seemed to be suggesting that the front-end should do any localisation. I was just saying that GDB has to do it because it is often run from the command line. Also you didn't respond to Eli's suggestion to arrange for your front end to push LC_MESSAGES=C into the environment when it runs GDB. > >The error message "Unrecognized option" is not intended to provide > >information > >about the GDB version. If you want to use it for that purpose, thats your > >choice, but you can hardly expect the GDB community to "support" that > >feature. > > I don't get your point. A front-end can decide how it wants to interpret an > error message as it pleases. I do it because this is the error I get when > -i=mi is used on a version that does not support it at all. It makes sense > in that context since I'm building the command line. Quite apart from localisation, at some stage it might also make sense to someone, to change the message to "Unsupported option". I don't think you can rely on these messages to be cast in stone. > I don't particular like to hard-code these strings. The list of messages I > gave previously are all marked as console-stream-output. What I am saying is > that localizing such error messages will hurt MI dependant tools since the > messages are highly useful for the front-end. I'm not sure what purpose > console-output really has in a Machine Interface as it tends to make sense > only to humans - but I guess some systems are making use of them. > > What I'd really like is to see them also wrapped in result-records (sample; > ignore syntax): > > ^failed,type="init-option-unrecognized",msg="Unrecognized option" > > Does that make any sense? We've already got ^error as a result field so it doesn't make any sense to me, and if "Unrecognized option" comes from the console stream then I think that can still change. The problem seems to be that of handling CLI error output in MI. I see that the standard GNU error function provides for an error number which is less likely to change: -- Function: void error (int STATUS, int ERRNUM, const char *FORMAT, ...) I wonder if GDB's error function could have one for MI e.g &"Unrecognized option\n" ^error,msg="Unrecognized option",code="35" or even &"Unrecognized option\n" ^error,code="35" instead of just: &"Unrecognized option\n" ^error,msg="Unrecognized option" Nick Nick