Re: [bug-gnulib] Re: getopt and Solaris 10

[Karl Berry]

GNU getopt tries to do too much when it reorders the commandline and
therefor needs the "+" as a workaround.

I don't suppose it matters at this point, but I fail to see the
connection here.  You can tell GNU getopt to REQUIRE_ORDER instead of
PERMUTE without using +, either directly or setting POSIXLY_CORRECT in
various ways.  See the __ordering enum in getopt_int.h, for example.
(Seems like you probably already know this, so maybe it's unsuitable
somehow, if so, sorry for the noise.)

Also, I don't agree that it is "doing too much" to have PERMUTE be the
default for GNU.  It is very useful for most programs.  cvs has
exceptional command-line parsing needs.

Happy hacking,
karl


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Karl Berry wrote:

> GNU getopt tries to do too much when it reorders the commandline and
> therefor needs the "+" as a workaround.
>
>I don't suppose it matters at this point, but I fail to see the
>connection here. You can tell GNU getopt to REQUIRE_ORDER instead of
>PERMUTE without using +, either directly or setting POSIXLY_CORRECT in
>various ways.


I'd rather not control a function I'm calling by messing with
environment variables, especially those that may have other side effects.

> See the __ordering enum in getopt_int.h, for example.
>(Seems like you probably already know this, so maybe it's unsuitable
>somehow, if so, sorry for the noise.)


It doesn't look to me like there is an easy way to set this from a
caller of getopt().

>Also, I don't agree that it is "doing too much" to have PERMUTE be the
>default for GNU. It is very useful for most programs. cvs has
>exceptional command-line parsing needs.


True.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgV4aLD1OTBfyMaQRAtYPAJ9q5KLtCt4T7JwYHNWSLqgPMKe2sgCg4D9I
OIkpN56K4vKZXgSvo0tFmJM=
=iNeT
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

Paul Eggert wrote:

>Derek Price <[EMAIL PROTECTED]> writes:
>
>  
>
>>Revised patch attached.
>>
>>
>
>Thanks; I installed the following slightly-different patch.
>  
>


Works for me.  Thanks Paul.

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Paul Eggert]

Derek Price <[EMAIL PROTECTED]> writes:

> Revised patch attached.

Thanks; I installed the following slightly-different patch.

2005-05-10  Derek Price  <[EMAIL PROTECTED]>

* getopt.m4 (gl_GETOPT): Check for Solaris 10 bug, not decl, when
possible.

--- getopt.m4   6 May 2005 01:04:20 -   1.9
+++ getopt.m4   10 May 2005 19:11:00 -  1.10
@@ -1,4 +1,4 @@
-# getopt.m4 serial 8
+# getopt.m4 serial 9
 dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -39,8 +39,27 @@ AC_DEFUN([gl_GETOPT],
 dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
 dnl option string (as of 2005-05-05).
 if test -z "$GETOPT_H"; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include ])
+  AC_CACHE_CHECK([for working GNU getopt function], 
[gl_cv_func_gnu_getopt],
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include ],
+  [[
+char *myargv[3];
+myargv[0] = "conftest";
+myargv[1] = "-+";
+myargv[2] = 0;
+return getopt (2, myargv, "+a") != '?';
+   ]])],
+[gl_cv_func_gnu_getopt=yes],
+[gl_cv_func_gnu_getopt=no],
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+  [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+  [#include ])])])
+  if test "$gl_cv_func_gnu_getopt" = "no"; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n "$GETOPT_H"; then


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Larry Jones]

Derek Price writes:
> 
> Okay, looking at that in C89 now, but just out of curiosity, if argv
> needs to be NULL terminated, what's the point of argc?

I believe it was added for convenience back in the dark ages.  All the
Unix exec functions require a null-terminated argument list (and don't
have an explicit argument count), so argv has naturally always been null
terminated.  (And the C Standard codified that behavior: at program
startup, argv[argc] is required to be null.)

-Larry Jones

I don't think that question was very hypothetical at all. -- Calvin


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Kurz wrote:

>I'm running out of time. I have to quit. Thanks very much for your effords.
>When there is something to test, i'll still try to help.


No problem.  Thanks for your help, Matthias.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgL7qLD1OTBfyMaQRAgNTAJ4yFV0txiOeuKI9/459BArLy7iVSACfYZhj
oP6Fu8IWbqICpJRFhSP376o=
=LDtS
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

Paul Eggert wrote:

>Derek Price <[EMAIL PROTECTED]> writes:
>
>
>  
>
>>+ myargv[[0]] = "conftest";
>>+ myargv[[1]] = "-+";
>>
>>
>
>This doesn't null-terminate myargv.
>  
>

Okay, looking at that in C89 now, but just out of curiosity, if argv
needs to be NULL terminated, what's the point of argc?

Revised patch attached.  I restored a comment I probably shouldn't have
cut as well.

2005-05-10  Derek Price  <[EMAIL PROTECTED]>

* m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible.


Regards,

Derek
Index: m4/getopt.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/getopt.m4,v
retrieving revision 1.9
diff -u -p -r1.9 getopt.m4
--- m4/getopt.m46 May 2005 01:04:20 -   1.9
+++ m4/getopt.m410 May 2005 13:56:05 -
@@ -39,8 +39,26 @@ AC_DEFUN([gl_GETOPT],
 dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
 dnl option string (as of 2005-05-05).
 if test -z "$GETOPT_H"; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include ])
+  AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt,
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include ],[
+ char *myargv[[3]];
+ myargv[[0]] = "conftest";
+ myargv[[1]] = "-+";
+ myargv[[2]] = NULL;
+ return '?' != getopt (2, myargv, "+a");
+])],
+gl_cv_func_gnu_getopt=yes,
+gl_cv_func_gnu_getopt=no,
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+ [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+[#include ])])])
+  if test "$gl_cv_func_gnu_getopt" = "no"; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n "$GETOPT_H"; then
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

Paul Eggert wrote:

>Derek Price <[EMAIL PROTECTED]> writes:
>
>
>  
>
>>+ myargv[[0]] = "conftest";
>>+ myargv[[1]] = "-+";
>>
>>
>
>This doesn't null-terminate myargv.
>
>But I still don't get why the change is needed.  It sounds like you're
>assuming Solaris 11 getopt might get fixed?  
>

Yes, I suppose so, or a later patch release of Solaris 10.  Or some
other system that decides to ship a getopt.h with a getopt_long(),
getopt_clip(), and a GNU compatible getopt(), however unlikely that may
sound now.

>But even in that case,
>the current code will work, right, since it will use GNU getopt?  So
>this is just an optimization for the hypothetical case if Solaris 11
>getopt gets fixed?  
>

Basically.  I was feeling guilty about not detecting the bug, but
detecting a feature of the system and assuming the bug.  This goes
against the whole Autoconf test design philosophy, I thought.  It's
almost as bad as using `uname -a |sed' to detect the version number and
using that to decide against the system getopt(), really.

The new test detects the actual bug.

>In that case perhaps we should wait for Solaris 11
>and test it before installing this patch, as it's more likely to cause
>a bug than to fix one.
>  
>

What sort of bug are you worried about?

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Matthias Kurz]

On Tue, May 10, 2005, Matthias Kurz wrote:

> On Mon, May 09, 2005, Paul Eggert wrote:
> 
[...]
> > But I still don't get why the change is needed.  It sounds like you're
> > assuming Solaris 11 getopt might get fixed?  But even in that case,
> > the current code will work, right, since it will use GNU getopt?  So
> > this is just an optimization for the hypothetical case if Solaris 11
> > getopt gets fixed?  In that case perhaps we should wait for Solaris 11
> > and test it before installing this patch, as it's more likely to cause
> > a bug than to fix one.
> 
> Well, it might still fail on other OSes, that also do not use GNU getopt.
> They do probably also not have the getopt_clip. I'll check this on IRIX,
> today.

The "vanilla" cvs-1.12.12 builds on irix and seems to run. The included
GNU getopt is used. There is a getopt.h, but no getopt_long_only. Thought,
Derek's test for "-+" would be necessary, but that's not the case. I do not
have autoconf and automake, there, so i cannot test the various patches. 
I'm running out of time. I have to quit. Thanks very much for your effords.
When there is something to test, i'll still try to help.


   (mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
  >> Im prämotorischen Cortex kann jeder ein Held sein. (bdw) <<


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Matthias Kurz]

On Mon, May 09, 2005, Paul Eggert wrote:

> Derek Price <[EMAIL PROTECTED]> writes:
> 
> 
> > + myargv[[0]] = "conftest";
> > + myargv[[1]] = "-+";
> 
> This doesn't null-terminate myargv.

D'oh !

> But I still don't get why the change is needed.  It sounds like you're
> assuming Solaris 11 getopt might get fixed?  But even in that case,
> the current code will work, right, since it will use GNU getopt?  So
> this is just an optimization for the hypothetical case if Solaris 11
> getopt gets fixed?  In that case perhaps we should wait for Solaris 11
> and test it before installing this patch, as it's more likely to cause
> a bug than to fix one.

Well, it might still fail on other OSes, that also do not use GNU getopt.
They do probably also not have the getopt_clip. I'll check this on IRIX,
today.


   (mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
  >> Im prämotorischen Cortex kann jeder ein Held sein. (bdw) <<


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Paul Eggert]

Derek Price <[EMAIL PROTECTED]> writes:


> + myargv[[0]] = "conftest";
> + myargv[[1]] = "-+";

This doesn't null-terminate myargv.

But I still don't get why the change is needed.  It sounds like you're
assuming Solaris 11 getopt might get fixed?  But even in that case,
the current code will work, right, since it will use GNU getopt?  So
this is just an optimization for the hypothetical case if Solaris 11
getopt gets fixed?  In that case perhaps we should wait for Solaris 11
and test it before installing this patch, as it's more likely to cause
a bug than to fix one.


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

Derek Price wrote:

>>>2005-05-05  Paul Eggert  <[EMAIL PROTECTED]>
>>>
>>> * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
>>> avoid needless checks.   
>>>  
>>>
>>Yes, this also works for me.
>>
>>
>
>Okay, one more revision, to actually check if the -+ registers as an
>option or not.  This fits the autoconf paradigm of testing for the bug,
>even if it is using AC_TRY_RUN.  This way, if Sun fixes the problem in a
>later Solaris release, we shouldn't need to change anything.
>
>When cross-compiling, I fall back on looking for the odd Solaris decl to
>decide whether to use the GNULIB version of getopt or not.  If we wanted
>to be really pessimistic, we could always use the GNULIB getopt when
>cross-compiling, but I thought this could wait at least until we get a
>report of similar behavior from some system other than Solaris 10.
>
>Matthias, would you mind testing this version out?  If you could send me
>your config.log when you are done building, that would be helpful as well.
>
>2005-05-09  Derek Price  <[EMAIL PROTECTED]>
>
>* m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible.
>  
>

I've attached almost the same patch as before, except that I remembered
to put `$' in front of all my variables this time.  Matthias confirmed
that ithis new patch does the right thing on Solaris 10.

This patch is against Paul's last commit.

Cheers,

Derek
Index: m4/getopt.m4
===
RCS file: /cvs/ccvs/m4/getopt.m4,v
retrieving revision 1.7
diff -u -p -r1.7 getopt.m4
--- m4/getopt.m46 May 2005 15:50:05 -   1.7
+++ m4/getopt.m49 May 2005 20:20:00 -
@@ -36,11 +36,26 @@ AC_DEFUN([gl_GETOPT],
   AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include ])
 fi
 
-dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
-dnl option string (as of 2005-05-05).
 if test -z "$GETOPT_H"; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include ])
+  AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt,
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include ],[
+ char *myargv[[2]];
+ myargv[[0]] = "conftest";
+ myargv[[1]] = "-+";
+ return '?' != getopt (2, myargv, "+a");
+])],
+gl_cv_func_gnu_getopt=yes,
+gl_cv_func_gnu_getopt=no,
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+ [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+[#include ])])])
+  if test "$gl_cv_func_gnu_getopt" = "no"; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n "$GETOPT_H"; then
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

...I know you already agreed...  ...I just thought this was interesting...

In fact, Solaris 10 is the one actually sticking to the letter of the
POSIX spec here, not that I think that assuming argv[0] should not be
processed is going to hurt the GNU version:

The variable /optind/ is the index of the next element of the
/argv/[] vector to be processed. It is initialised to 1 by the system,

...

If, when /getopt()/ is called:

|
 /argv/[optind]is a null pointer
*/argv/[optind]is not the character -
 /argv/[optind]points to the string "-"
|

 /getopt/() returns -1 without changing /optind./


Cheers,

Derek


Derek Price wrote:

>Regardless, since using an optind = 0 is not specified as supported by
>POSIX, whereas optind = 1 is, and since using optind = 1 in place of
>optind = 0 in CVS would avoid this problem on all platforms and with all
>versions of getopt (supporting optind = 0 provides no additional
>functionality that I know of), I don't think this is properly considered
>a Solaris bug, but a CVS bug.
>
>At least, it would be a CVS bug if we didn't have to use the GNU getopt
>on Solaris due to the "+" problem anyhow.
>
>Cheers,
>
>Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf55NLD1OTBfyMaQRApD/AKDG91RXkmD1GjNyqLJmzFjQq9vCBwCfbjTw
HHeRY0WAPlT67fsFFn0PNuE=
=oFUI
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

Regardless, since using an optind = 0 is not specified as supported by
POSIX, whereas optind = 1 is, and since using optind = 1 in place of
optind = 0 in CVS would avoid this problem on all platforms and with all
versions of getopt (supporting optind = 0 provides no additional
functionality that I know of), I don't think this is properly considered
a Solaris bug, but a CVS bug.

At least, it would be a CVS bug if we didn't have to use the GNU getopt
on Solaris due to the "+" problem anyhow.

Cheers,

Derek


Derek Price wrote:

> Matthias Kurz wrote:
>
> >Hi.
>
> >One more clarification. Maybe one or the other missed my last comments
> >on . It was me,
> >who introduced the "'+' myth".
>
>
>
> Well, it is not a myth.  I studied the test program and output you sent
> me, and Solaris does, indeed, treat the initial "+" as an option rather
> than a request for getopt() semantics.
>
> >I "analysed" the problem wrong in the
> >beginning. It is not exactly the "+" that makes the problem, but the
> >fact, that the Solaris getopt refuses to accept a zero value on optind.
> >When "optind==0", the Solaris getopt returns -1 immediately, leaving
> >optind==0. W
>
>
>
> I did read this correctly in your report.  If anyone else sees a need
> for an actual test for correct optind=0 behavior, then they are welcome
> to write one, but I decided the point was moot at the moment since
> detecting the "+" bug, just as valid as a means of selecting the GNU
> getopt() over the system one, was sufficient to avoid encountering any
> other bugs in the Solaris getopt().
>
> Cheers,
>
> Derek


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs





___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Matthias Kurz]

On Mon, May 09, 2005, Derek Price wrote:

[...]
> I did read this correctly in your report.  If anyone else sees a need
> for an actual test for correct optind=0 behavior, then they are welcome
> to write one, but I decided the point was moot at the moment since
> detecting the "+" bug, just as valid as a means of selecting the GNU
> getopt() over the system one, was sufficient to avoid encountering any
> other bugs in the Solaris getopt().

I agree with you.


   (mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
  >> Im prämotorischen Cortex kann jeder ein Held sein. (bdw) <<


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Kurz wrote:

>Hi.
>
>One more clarification. Maybe one or the other missed my last comments
>on . It was me,
>who introduced the "'+' myth".


Well, it is not a myth.  I studied the test program and output you sent
me, and Solaris does, indeed, treat the initial "+" as an option rather
than a request for getopt() semantics.

>I "analysed" the problem wrong in the
>beginning. It is not exactly the "+" that makes the problem, but the
>fact, that the Solaris getopt refuses to accept a zero value on optind.
>When "optind==0", the Solaris getopt returns -1 immediately, leaving
>optind==0. W


I did read this correctly in your report.  If anyone else sees a need
for an actual test for correct optind=0 behavior, then they are welcome
to write one, but I decided the point was moot at the moment since
detecting the "+" bug, just as valid as a means of selecting the GNU
getopt() over the system one, was sufficient to avoid encountering any
other bugs in the Solaris getopt().

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf5lsLD1OTBfyMaQRAiT1AJ9SOugiUFKjruvZOCi23ko9wLqGLwCg2S/R
DTImJNqzmHIonAUGmka+CNg=
=OKfo
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Kurz wrote:

>I do not think that this is a Solaris _bug_.


- From the point of view of the GNULIB getopt.m4 tests, if it doesn't
behave like GNU getopt, that is a bug.  :)

>I'd bet that every system that does not use GNU getopt will suffer from
>this problem. I don't know how many of them have a getopt.h, which
>"triggers" the problem.


Well, yes, in a sense, but the tests in m4/getopt.m4 had already
eliminated all systems which don't declare a getopt_long() in favor of
the included getopt.c file from GNULIB, assuming that if getopt_long()
was declared then we could expect GNU getopt() semantics as well. 
getopt_long() is a GNU extension and not part of any standard that I
know of.

Unfortunately, in the sense that it broke the existing GNULIB getopt.m4
tests, the Solaris folks decided they liked the getopt_long() function
and imported it, without updating their getopt() to match, thereby
breaking the assumption getopt.m4 had been making thus far.

>>Matthias, would you mind testing this version out? If you could send me
>>your config.log when you are done building, that would be helpful as well.
>
>
>Yes, i'm going to test this asap.


Thanks.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf49SLD1OTBfyMaQRAucQAKCZ1j8EtPQaa+1KqZSx3VGKGYvy2wCfeu4t
fgBXhyz5M7ewzUcAydnxtv0=
=oNlX
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Matthias Kurz]

Hi.

One more clarification. Maybe one or the other missed my last comments
on . It was me,
who introduced the "'+' myth". I "analysed" the problem wrong in the
beginning. It is not exactly the "+" that makes the problem, but the
fact, that the Solaris getopt refuses to accept a zero value on optind.
When "optind==0", the Solaris getopt returns -1 immediately, leaving
optind==0. When the cvs processing continues, it takes all arguments
left as "file" argument - alas all arguments from the commandline. I
looked at the sources, saw the "+", red the GNU getopt manpage that
states, that the "+" prevents a reorder of the commandline and took
the wrong conclusion, that the _Solaris_ getopt reorders the commandline.

I thought, that using the GNU getopt is still the best solution, because
this is minimal intrusive to the cvs sources and because the fix is
in the gnulib, so other projects, where optind is also set to zero, will
profit from it. When one sets optind to 1, before getopt is entered, this
should also fix the problem.  That the Solaris getopt would accept an
option "-+" would just be an ugly side effect. But who knows, what effects
the setting of optint to 1 has on other platforms, where cvs always worked.

I did not want to think that much, so i said from the beginning on "just
use the GNU implementation everywhere". Who needs standards, when there is
a source ?


   (mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
  >> Im prämotorischen Cortex kann jeder ein Held sein. (bdw) <<


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Matthias Kurz]

On Mon, May 09, 2005, Derek Price wrote:

[...]
> Okay, one more revision, to actually check if the -+ registers as an
> option or not.  This fits the autoconf paradigm of testing for the bug,
> even if it is using AC_TRY_RUN.  This way, if Sun fixes the problem in a
> later Solaris release, we shouldn't need to change anything.

I do not think that this is a Solaris _bug_. GNU getopt tries to do too
much when it reorders the commandline and therefor needs the "+" as a
workaround. I would not hold my breath to wait for a "fix" from the Sun
side. But then, as long as it works for me, i'm happy with everything.

> When cross-compiling, I fall back on looking for the odd Solaris decl to
> decide whether to use the GNULIB version of getopt or not.  If we wanted
> to be really pessimistic, we could always use the GNULIB getopt when
> cross-compiling, but I thought this could wait at least until we get a
> report of similar behavior from some system other than Solaris 10.

I'd bet that every system that does not use GNU getopt will suffer from
this problem. I don't know how many of them have a getopt.h, which
"triggers" the problem.

> Matthias, would you mind testing this version out?  If you could send me
> your config.log when you are done building, that would be helpful as well.

Yes, i'm going to test this asap.


   (mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
  >> Im prämotorischen Cortex kann jeder ein Held sein. (bdw) <<


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

Matthias Kurz wrote:

>On Thu, May 05, 2005, Paul Eggert wrote:
>
>  
>
>>Derek Price <[EMAIL PROTECTED]> writes:
>>
>>
>>
>>>I prefer door #2.  Trivial patch attached:
>>>  
>>>
>>Thanks, but I'd rather use AC_CHECK_DECL, so I installed this instead,
>>into both coreutils and gnulib.  Does it work?
>>
>>2005-05-05  Paul Eggert  <[EMAIL PROTECTED]>
>>
>>  * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
>>  avoid needless checks.
>>
>>
>
>Yes, this also works for me.
>  
>

Okay, one more revision, to actually check if the -+ registers as an
option or not.  This fits the autoconf paradigm of testing for the bug,
even if it is using AC_TRY_RUN.  This way, if Sun fixes the problem in a
later Solaris release, we shouldn't need to change anything.

When cross-compiling, I fall back on looking for the odd Solaris decl to
decide whether to use the GNULIB version of getopt or not.  If we wanted
to be really pessimistic, we could always use the GNULIB getopt when
cross-compiling, but I thought this could wait at least until we get a
report of similar behavior from some system other than Solaris 10.

Matthias, would you mind testing this version out?  If you could send me
your config.log when you are done building, that would be helpful as well.

2005-05-09  Derek Price  <[EMAIL PROTECTED]>

* m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible.

Cheers,

Derek
Index: m4/getopt.m4
===
RCS file: /cvs/ccvs/m4/getopt.m4,v
retrieving revision 1.7
diff -u -p -r1.7 getopt.m4
--- m4/getopt.m46 May 2005 15:50:05 -   1.7
+++ m4/getopt.m49 May 2005 14:47:15 -
@@ -36,11 +36,26 @@ AC_DEFUN([gl_GETOPT],
   AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include ])
 fi
 
-dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
-dnl option string (as of 2005-05-05).
 if test -z "$GETOPT_H"; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include ])
+  AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt,
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include ],[
+ char *myargv[[2]];
+ myargv[[0]] = "conftest";
+ myargv[[1]] = "-+";
+ return '?' != getopt (2, myargv, "+a");
+])],
+gl_cv_func_gnu_getopt=yes,
+gl_cv_func_gnu_getopt=no,
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+ [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+[#include ])])])
+  if test gl_cv_func_gnu_getopt = "no"; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n "$GETOPT_H"; then
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Matthias Kurz]

On Thu, May 05, 2005, Paul Eggert wrote:

> Derek Price <[EMAIL PROTECTED]> writes:
> 
> > I prefer door #2.  Trivial patch attached:
> 
> Thanks, but I'd rather use AC_CHECK_DECL, so I installed this instead,
> into both coreutils and gnulib.  Does it work?
> 
> 2005-05-05  Paul Eggert  <[EMAIL PROTECTED]>
> 
>   * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
>   avoid needless checks.

Yes, this also works for me.

   Thanks

(mk)

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
  >> Im prämotorischen Cortex kann jeder ein Held sein. (bdw) <<


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Paul Eggert]

Derek Price <[EMAIL PROTECTED]> writes:

> I prefer door #2.  Trivial patch attached:

Thanks, but I'd rather use AC_CHECK_DECL, so I installed this instead,
into both coreutils and gnulib.  Does it work?

2005-05-05  Paul Eggert  <[EMAIL PROTECTED]>

* lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
avoid needless checks.

--- getopt.m4.~1.8.~2005-01-23 00:06:57 -0800
+++ getopt.m4   2005-05-05 17:53:53 -0700
@@ -1,5 +1,5 @@
-# getopt.m4 serial 7
-dnl Copyright (C) 2002, 2003, 2004 Free Software Foundation, Inc.
+# getopt.m4 serial 8
+dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
@@ -26,11 +26,22 @@ AC_DEFUN([gl_GETOPT],
   if test -z "$GETOPT_H"; then
 GETOPT_H=
 AC_CHECK_HEADERS([getopt.h], [], [GETOPT_H=getopt.h])
-AC_CHECK_FUNCS([getopt_long_only], [], [GETOPT_H=getopt.h])
+if test -z "$GETOPT_H"; then
+  AC_CHECK_FUNCS([getopt_long_only], [], [GETOPT_H=getopt.h])
+fi
 
 dnl BSD getopt_long uses an incompatible method to reset option processing,
 dnl and (as of 2004-10-15) mishandles optional option-arguments.
-AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include ])
+if test -z "$GETOPT_H"; then
+  AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include ])
+fi
+
+dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+dnl option string (as of 2005-05-05).
+if test -z "$GETOPT_H"; then
+  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
+   [#include ])
+fi
 
 if test -n "$GETOPT_H"; then
   gl_GETOPT_SUBSTITUTE


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Price wrote:

>2005-05-05 Derek Price <[EMAIL PROTECTED]>
>
> * m4/getopt.m4 (gl_GETOPT): Use GNULIB getopt on Solaris 10.


Matthias reports that this patch does The Right Thing (tm) on Solaris
10: .

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCeoCwLD1OTBfyMaQRAhMHAJ0R2a//oSHXiFaNMjMHTbBP2nGq4gCghqjB
plPDozD5LBe5LAyjHA46zQ8=
=ChvA
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs