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 Message-ID: <00b301c2c7ff$c646c5b0$78d96f83@pomello> From: "Max Bowsher" To: References: <001301c2c7e8$11fb57e0$78d96f83 AT pomello> <20030130011501 DOT GB3603 AT redhat DOT com> Subject: Re: getopt_long behavior Date: Thu, 30 Jan 2003 01:34:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Christopher Faylor wrote: > On Wed, Jan 29, 2003 at 10:45:06PM -0000, Max Bowsher wrote: >> would you accept a patch making getopt respond to a >> "POSIXLY_INCORRECT_GETOPT" envvar? > > I'll make the change but it won't have the effect you think it will. > I guarantee it. I will even make a snapshot and then you can watch > in horror and amazement as setting the environment variable has no > effect. > > And for an answer to the riddle of why this won't immediately do what > you want, try this in the winsup/cygwin directory: > > grep -i getopt cygwin.din > > (Remember not to put the -i at the end!) Ah. This suggests that the ideal fix would be to have alternate object files for getopt, such that programs which really can't cope with getopt's reordering can surpress it at link time - something along the lines of automode.o, textmode.o, etc. Max. -- 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/