From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2566 invoked by alias); 25 Jul 2002 00:14:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2518 invoked from network); 25 Jul 2002 00:14:20 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 25 Jul 2002 00:14:20 -0000 Received: from dhcp-172-16-25-188.sfbay.redhat.com (vpn3-2.sfbay.redhat.com [172.16.25.2]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g6P0EaQ29759; Wed, 24 Jul 2002 17:14:36 -0700 Subject: naming command arguments From: Anthony Green To: gdb@sources.redhat.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 24 Jul 2002 17:14:00 -0000 Message-Id: <1027556059.2082.179.camel@dhcppc2> Mime-Version: 1.0 X-SW-Source: 2002-07/txt/msg00257.txt.bz2 I've been talking to some GDB users who are frustrated with some of GDB's command syntax. My understanding is that optional command arguments must be the last possible arguments, and they get dropped off right to left. The problem is that some GDB commands have multiple arguments, all of which make sense to be optional, but in no particular order. So, for instance, the restore command looks something like: restore FILENAME [OFFSET [START [STOP]]] In this case, if you only want to specify the START argument, your forced to give OFFSET argument. They're suggestion, which seems to make sense to me, is to introduce the concept of named parameters for GDB commands. So, in my previous example, they could simply write... restore FILENAME start:VALUE ...and let GDB make reasonable assumptions about OFFSET and STOP How do people feel about introducing these kinds of arguments to certain GDB commands (like restore)? AG