From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25420 invoked by alias); 1 Jun 2007 19:12:15 -0000 Received: (qmail 25413 invoked by uid 22791); 1 Jun 2007 19:12:15 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Jun 2007 19:12:13 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l51JCB4m009742 for ; Fri, 1 Jun 2007 15:12:11 -0400 Received: from pobox.hsv.redhat.com (pobox.hsv.redhat.com [172.16.16.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l51JCBqT017237; Fri, 1 Jun 2007 15:12:11 -0400 Received: from [10.11.14.184] (vpn-14-184.rdu.redhat.com [10.11.14.184]) by pobox.hsv.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l51JC95J009893; Fri, 1 Jun 2007 15:12:10 -0400 Message-ID: <46606F89.5050805@redhat.com> Date: Fri, 01 Jun 2007 19:13:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Nurdin Premji CC: frysk Subject: Re: Command line utilities argument types. References: <46606E0E.3050804@redhat.com> In-Reply-To: <46606E0E.3050804@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00233.txt.bz2 Nurdin Premji wrote: > I'm going to be refactoring how the command line utilities will parse > their arguments to make them as unified as possible. > > I've identified 4 types of input that can be passed to a command line > utility: Pids, Core files, a command (executable with options), or > nothing. > > Here is my interpretation of which command line utilities can take > what types of arguments. How would you classify options (like logging and other behavior modifiers, like -a for all maps output for fcore)? Or is that not going to be touched by this refactor?. FWIW fcore can take one or many pids, can take logging options and can take an optional -a parameter to dump all maps instead of selecting the maps based on historical precedence of what to write/what to elide. Regards Phil