From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 1/8] Add core.sh and wrapper function Date: Tue, 14 Apr 2015 15:44:13 +0100 Message-ID: <552D27BD.8060501@eu.citrix.com> References: <1428607792-13418-1-git-send-email-george.dunlap@eu.citrix.com> <1428607792-13418-2-git-send-email-george.dunlap@eu.citrix.com> <552B9D71.1020702@eu.citrix.com> <1429019721.15516.59.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1429019721.15516.59.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Stefano Stabellini Cc: Stefano Stabellini , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 04/14/2015 02:55 PM, Ian Campbell wrote: > On Mon, 2015-04-13 at 17:13 +0100, Stefano Stabellini wrote: >> I think it might be OK to have something like 5) just for the command >> line parsing in raise, for the sake of giving more flexibility to the >> user. Also it would be confined to one specific call site. But I am >> uncertain that the pros outweigh the cons in this case. > > I've only glanced at it, but isn't this largely replicating getopt(1)? > Perhaps without requiring -- on the options, but having the -- is more > conventional I think. For the top-level command-line parsing, yeah, I wouldn't think introducing that crazy macro would be worth it; doing getopt just the one time is probably worth it. For the internal calling convention, setting up getopt at the top fo every single function would be a nightmare. I have been using the $arg_parse calling convention in my own script library for several years now, and believe me, it is a *lot* nicer. -George