From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21284 invoked by alias); 9 Apr 2012 21:42:47 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 17001 Received: (qmail 26736 invoked from network); 9 Apr 2012 21:42:45 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120409144225.ZM28987@torch.brasslantern.com> Date: Mon, 09 Apr 2012 14:42:25 -0700 In-reply-to: Comments: In reply to toki clover "zsh[modules]/zutil: zparseopts should parse alternate long options" (Apr 9, 2:12pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: toki clover , zsh-users@zsh.org Subject: Re: zsh[modules]/zutil: zparseopts should parse alternate long options MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Apr 9, 2:12pm, toki clover wrote: } } Now, it would be nice if an alternate long option e.g. `-option' } instead of the GNU style `--option' would work, because in the present } day, if the first letter of a long option name is a short option name, } the long option would never be parsed as one would expect. An example would help to clarify your question. Do any of the following explain what you mean? If not, could you provide a sample? Given ARGV=(-option) zparseopts o=shortopts option=longopts the entire string "-option" will be placed in the array "$longopts", which seems to be what you want. Given ARGV=(-option -o) zparseopts o=shortopts option=longopts then $shortops will contain "-o" and $longopts will contain "-option". In fact zparseopts normally attempts to make the longest match first, so except in ambiguous cases option=longopts will always consume -option before o=shortopts is attempted. Only when no spec is matched that can be treated as a single element does zparseopts fall back to handling the prefix of -option as if it were -o. The ambigous case happens with zparseopts option=longopts o:=shortopts where -option could be parsed as either [-o with argument ption] or as [-option]. The above would place (-o ption) in $shortopts and leave nothing for $longopts. However, this can be handled by making two passes with separate specs: zparseopts -E -D option=longopts zparseopts -D o:=shortopts In fact as currently implemented zparseopts scans the specs in reverse order from last to first, so the above two passes are the same as zparseopts -D o:=shortopts option=longopts but that's undocumented so not guaranteed to remain the case. Since using -E is an imperfect solution for the two-pass example, it would probably not be unreasonable to suggest that the search order should become documented and therefore trustworthy.