Re: [bug-gnulib] Re: getopt and Solaris 10
-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
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
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
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: lockinfo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: > I honestly don't know if it is a good idea to > introduce this patch to feature in this way at > this time. > > What do the other maintainers think of this kind > of extension? I don't have a strong opinion either way. Some users might find it useful to have read ACLs made available this way. Me, I prefer to offload any ACL decisions on the file system since it is almost certainly more secure. As long as I don't have to do the work, though, and without thinking deeply about your discussion about whether soft or hard failures are better, I have no objections to this patch. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCgMRDLD1OTBfyMaQRAs1XAJ9Pu3LSUAoKAPaF67L8oiKlIfBuugCfXay/ t2xW87sMgKYXgcbk4bW4PdI= =D8vS -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
-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
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
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
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: lockinfo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kendy Kutzner <[EMAIL PROTECTED]> writes:
> On 2005-05-09T11:25:06-0700, Mark D. Baushke wrote:
> > > - empty/nonexistent lockinfo: everything should work as ever
> > > - layout $CVSROOT/a, $CVSROOT/a/b, $CVSROOT/c
> > > - lockinfo contains
> > > ^a false
> > > ^a/b true
> > > - checkout a should fail
> > > - checkout b should work (i'm not too sure)
> >
> > I believe CVS processes directories
> > alphabetically depth-first. So, in this case,
> > b would also fail unless you explicitly did a
> >
> > cvs checkout a/b
>
> you are right, that's what i'm talking about
> when i wrote 'checkout b'
Okay. I just wanted to be clear what was the
expected output of the designer of the patch.
> > In point of fact, the addition of this new
> > feature may be a good time to alter how cvs
> > works.
>
> as long as i don't have to write it :)
Yup, I understand that feeling very well indeed... :-)
> > If you are explicitly controlling checkout
> > behavior, then you could choose to non-fatally
> > skip directories for which you do not have
> > permissions... it would be as if they were
> > really private to some other set of users and
> > not even visible to the user implicitly trying
> > to check them out.
>
> Than CVS internals really have to be changed. My
> little patch makes the lock creation fail. When
> lock creation fails, CVS aborts the current
> operation. One possible change: first lock all
> directories which are going to be used. If all
> locks were successfully created, do the
> checkout: somehow
> if (start_recursion(lock..)){
> start_recursion(checkout..)
> start_recursion(unlock..)
> }
Yeah, it really would be easier to implement this
variation in a read-lock trigger if CVS were using
the lock manager of CVSNT instead of the current
way it does locks.
However, I don't really want to worry about that
feature of CVSNT right now.
> > Although it may be desirable to force an error
> > if the user explictly asked for a
> > 'read-locked' directory on the command line
> > instead of just running into one during the
> > checkout process.
>
> But as I said, that's exactly the behaviour when
> someone enforces 'dont read (dont create locks)'
> with file system permissions.
Okay.
> > Addition of this kind of 'read-lock' might be
> > considered to be 'better' than just use
> > operating-system directory permissions.
>
> It's not that elegant, but more flexible. And it
> works with all kinds of file systems.
Well, your patch acts in addition to the locks
imposed by ther other kinds of file systems
already supported...
> > I still remain unconvinced that the current
> > implementation of your patch is desirable.
>
> Since my patch is GPL, everyone is free to
> change it / ignore it. In which direction do you
> would change it?
I am not sure.
> > > +Before the lock is created, the @file{loginfo} in CVSROOT is
> >
> > The above line references `loginfo' instad of
> > `lockinfo' which seems wrong.
>
> Because it is wrong :)
> But I think I don't need to send a patch for that :)
True.
> > I suspect that some mention that this is for
> > read-locks instead of dealing with promotable
> > or write locks...
>
> I thought write locks are an entire different
> ball game? But feel free to correct me.
Sure, but the paragraph you added leaves ambiguity
that the trigger might also apply for other kinds
of locks. The idea would be to be clear in the
documentation that this particular trigger is NOT
used for anything other than read-locks.
> > it also begs the question as to the correct
> > name for this file being 'readinfo' instead of
> > 'lockinfo' ...
>
> As I wrote, anybody can change that.
Sure.
Okay. The patch is posted and there is at least
some idea of how to write the sanity.sh tests
for trivial exercise of it.
I honestly don't know if it is a good idea to
introduce this patch to feature in this way at
this time.
What do the other maintainers think of this kind
of extension?
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCgHbI3x41pRYZE/gRAqHNAJ9pN3V1IoCW56tFqhZyNYsoOye16ACgixS3
GIQQcdhLtqlnGzrMl5zK9IM=
=AwyR
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: lockinfo
On 2005-05-09T11:25:06-0700, Mark D. Baushke wrote:
> > - empty/nonexistent lockinfo: everything should work as ever
> > - layout $CVSROOT/a, $CVSROOT/a/b, $CVSROOT/c
> > - lockinfo contains
> > ^a false
> > ^a/b true
> > - checkout a should fail
> > - checkout b should work (i'm not too sure)
>
> I believe CVS processes directories alphabetically depth-first. So, in
> this case, b would also fail unless you explicitly did a
>
> cvs checkout a/b
you are right, that's what i'm talking about when i wrote 'checkout b'
> In point of fact, the addition of this new feature may be a good time to
> alter how cvs works.
as long as i don't have to write it :)
> If you are explicitly controlling checkout
> behavior, then you could choose to non-fatally skip directories for
> which you do not have permissions... it would be as if they were really
> private to some other set of users and not even visible to the user
> implicitly trying to check them out.
Than CVS internals really have to be changed. My little patch makes the
lock creation fail. When lock creation fails, CVS aborts the current
operation. One possible change: first lock all directories which are
going to be used. If all locks were successfully created, do the
checkout: somehow
if (start_recursion(lock..)){
start_recursion(checkout..)
start_recursion(unlock..)
}
> Although it may be desirable to
> force an error if the user explictly asked for a 'read-locked' directory
> on the command line instead of just running into one during the checkout
> process.
But as I said, that's exactly the behaviour when someone enforces 'dont
read (dont create locks)' with file system permissions.
> Addition of this kind of 'read-lock' might be considered to be 'better'
> than just use operating-system directory permissions.
It's not that elegant, but more flexible. And it works with all kinds of
file systems.
> I still remain unconvinced that the current implementation of your patch
> is desirable.
Since my patch is GPL, everyone is free to change it / ignore it. In
which direction do you would change it?
> > +Before the lock is created, the @file{loginfo} in CVSROOT is
> The above line references `loginfo' instad of `lockinfo' which seems
> wrong.
Because it is wrong :)
But I think I don't need to send a patch for that :)
> I suspect that some mention that this is for read-locks instead of
> dealing with promotable or write locks...
I thought write locks are an entire different ball game? But feel free
to correct me.
> it also begs the question as to the correct name for this file being
> 'readinfo' instead of 'lockinfo' ...
As I wrote, anybody can change that.
Kendy
--
pgpKKxZXZH7Le.pgp
Description: PGP signature
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
