Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 29 Jan 2003 17:48:16 -0500 From: Chris Morgan Subject: RE: getopt_long behavior To: lhall AT rfk DOT com Cc: cmorgan AT alum DOT wpi DOT edu, cygwin AT cygwin DOT com Reply-To: cmorgan AT alum DOT wpi DOT edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: I've never used a flavor of linux that didn't support arguments and options in arbitrary(within reason) order. I think if you started forcing users to enter options in a strict order you would be met with considerable resistance as this restriction is unnecessary. I'm not asking for every tool to accept arguments in different orders, I'm just asking ofr getopt_long() to accept reordering. All apps that use getopt_long() will then support argument reordering to the extent that getopt_long() does, all of the tools I use on linux boxes do so, including gcc and linker tools, without any trouble at all. This behavior actually used to be supported in cygwin but was changed, maybe a year or a year and a half ago. I just wanted to bring the issue back up again to see if cygwin tools could be made to work like their linux/unix counterparts again. Chris ---- Original message ---- >Date: Wed, 29 Jan 2003 17:42:57 -0500 >From: "lhall AT pop DOT ma DOT ultranet DOT com" >Subject: RE: getopt_long behavior >To: cmorgan AT alum DOT wpi DOT edu, cygwin AT cygwin DOT com > >Giving the impression that ordering of arguments is not significant >is not a good idea in general. Although what you're looking for is >an extreme, the fact that you can generally interchange the order >of flags ( grep -i -c *.c vs grep -c -i *.c) does generate expectations >for all tools. This uniformity isn't going to be met by all tools (like >gcc and linker flags). So adding to the flexibility as you suggest would >only tend to increase the inquiries and problems folks currently have for >these kinds of tools. I don't think it's wise to look at making any tool >accept any argument in any order. I expect you'd find this isn't practical >anyway. But, that's just my opinion and it ain't worth much! ;-) > >Reasonably speaking, Cygwin targets POSIX compatibility. For better >or worse, conforming to this standard comes with certain restrictions >on behavior. I can only offer the consolation that at least since >Cygwin is open-source, you have the option to build it the way you >want it, if you want it bad enough. ;-) > >Larry > > >Original Message: >----------------- >From: Chris Morgan chrismorgan AT rcn DOT com >Date: Wed, 29 Jan 2003 16:29:47 -0500 >To: cygwin AT cygwin DOT com >Subject: getopt_long behavior > > >I orginally posted this message some time ago. Having all of >the cygwin tools lacking the ability to accept arguments in >arbirtary order makes it more difficult to use them(I often do >grep "string" *.c and then rerun with -i at the end). Is >there anyway to get around this without recompiling the whole >cygwin suite from source code? Is there still no plan to >switch this behavior back? I can't imagine I'm the only one >that wishes reordering was supported. > >Thanks, >Chris > > >On Thu, Sep 05, 2002 at 04:52:01AM -0400, chrismorgan AT rcn DOT com >wrote: >>I noticed that getopt() and getopt_long() aren't doing >reordering of >>argv entries. Searching the cygwin-developers mailing list I >found >>that this is due to compiling with POSIXLY_CORRECT set. Is >there any >>plan to move back to not setting this variable? > >No. > >cgf > >-- >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >Bug reporting: http://cygwin.com/bugs.html >Documentation: http://cygwin.com/docs.html >FAQ: http://cygwin.com/faq/ > > >-------------------------------------------------------------------- >mail2web - Check your email from the web at >http://mail2web.com/ . > > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/