Troy, very good decision.
mg Am Freitag, 28. September 2007 schrieb Troy A. Griffitts: > Sorry this is escalating and an emotional issue. I'm not sure why it is > such. > > Thanks for all the buzz words. 20 lines added and commited. > > DM Smith <[EMAIL PROTECTED]> wrote: > >On Sep 27, 2007, at 1:49 PM, Troy A. Griffitts wrote: > >> DM, > >> > >> I'm sorry. I never intended to 'stifle community contribution'. I > >> was > >> merely trying to make a technical decision. If you describe to me a > >> benefit of importing 475 lines which we did not write or have any idea > >> if it is crossplatform-- to check 4 command line options to a tool > >> that > >> is only total 840 lines, then I might consider. > > > >You asked for one. Here is a bunch. > > > >Pros: > >Industry standard command line code. > >Reusable code. > >Becomes a pattern for new utilities, perhaps for existing utilities. > >Stable/proven code. > >POSIX standard. > >Usage is well-known, understood and used by many programmers. > >Easy to use. > >Easy to maintain. > >Easy to extend. > >Favorable license. > > > >Cons: > >Would need to be proven on various platforms. > >Not invented here. > > > >> But it seems to me we > >> could simple add a 20 line for loop to do the same. And I'm not > >> sure we > >> wouldn't still need to add the 20 line for loop if we imported this > >> code. Checking commandline arguments in C is not that hard. I don't > >> need a library to do it for me-- especially when our input > >> arguments are > >> neither lengthy, nor complex. > > > >Yes, checking command line options is not all that hard in C. But why > >reinvent the wheel? > > > >create a loop that > >checks first characters of argument for - or --, > >look for match against expected set of values > >when match found determine whether it requires an argument, > >if so get the argument and determine how to convert it to an > >appropriate internal representation > >based upon what was successfully passed determine whether > >disambiguation needs to occur, > >if so, disambiguate, saving value as appropriate. > >on error, report error and post usage statement. > > > >Granted some of the above needs to be done regardless of which > >implementation is used. > > > >> Please understand I'm only trying to make a technical decision. > > > >Another reason, I have further plans to enhance osis2mod to also take > >a valid OSIS commentary. I'm anticipating that will require more flag > >changes. Also, with Chris' change to do normalization, it may be > >necessary to pass in whether the encoding is UTF-8 or Latin-1. > > > >> -Troy. > >> > >> DM Smith wrote: > >>> Troy, > >>> > >>> I'm not sure what the dependency would be. The code is self-contained > >>> and 475 lines. The getsubopt.c is not needed unless getopt.h is > >>> used as > >>> is. As Chris notes, it can be isolated in the utilities directory not > >>> injecting dependency anywhere. The only other possible dependency is > >>> that of the license. If that is a problem, I will keep looking for a > >>> version with one that is not. > >>> > >>> Please don't stifle community contribution. > >>> > >>> DM > >>> > >>> Troy A. Griffitts wrote: > >>>> I think I would like to conclude this thread with deciding that > >>>> we are > >>>> not willing to introduce a dependency to iterate simple program > >>>> args. > >>>> Thank you all for the suggestion. > >>>> > >>>> -Troy. > >>>> > >>>> DM Smith wrote: > >>>>> How about this implementation, as it is pretty short: > >>>>> > >>>>> Header: > >>>>> http://www.mirbsd.org/cvs.cgi/src/include/getopt.h? > >>>>> rev=1.1.1.1;content-type=text%2Fplain > >>>>> > >>>>> Code: > >>>>> http://www.mirbsd.org/cvs.cgi/src/lib/libc/stdlib/getopt_long.c? > >>>>> rev=1.1.1.3;content-type=text%2Fplain > >>>>> http://www.mirbsd.org/cvs.cgi/src/lib/libc/stdlib/getsubopt.c? > >>>>> rev=1.3;content-type=text%2Fplain > >>>>> > >>>>> It is a BSD license that is compatible with GPL (some BSD are > >>>>> not) and > >>>>> it is self contained in one file. > >>>>> > >>>>> -- DM > >>>>> > >>>>> On Sep 26, 2007, at 5:15 PM, Chris Little wrote: > >>>>>> But Windows lacks it, I believe. > >>>>>> I suppose we could absorb some BSD code, assuming it were > >>>>>> short, to > >>>>>> achieve the same end, but we can't just #include <unistd.h>. > >>>>>> > >>>>>> --Chris > >>>>>> > >>>>>> Sergio QUEIROZ wrote: > >>>>>>> getopt without GNU extensions is a part of the Unix Base > >>>>>>> Specifications > >>>>>>> and should be available mostly everywhere. > >>>>>>> > >>>>>>> http://www.opengroup.org/onlinepubs/009695399/functions/ > >>>>>>> getopt.html > >>>>>>> > >>>>>>> Yours, > >>>>>>> > >>>>>>> Sergio > >>>>>>> > >>>>>>> Le mercredi 26 septembre 2007 à 11:35 -0700, Chris Little a > >>>>>>> > >>>>>>> écrit : > >>>>>>>> Eeli Kaikkonen wrote: > >>>>>>>>> On Tue, 25 Sep 2007, Troy A. Griffitts wrote: > >>>>>>>>>> As DM has said previously, it > >>>>>>>>>> would be really nice to have normal -options which are not > >>>>>>>>>> order > >>>>>>>>>> dependent. > >>>>>>>>> > >>>>>>>>> Using GNU getopt? > >>>>>>>>> http://www.gnu.org/software/libc/manual/html_node/Getopt.html > >>>>>>>> > >>>>>>>> Using anything from GNU would be a bad idea. Enduring "the chore > >>>>>>>> involved in parsing typical unix command line options" makes > >>>>>>>> our code > >>>>>>>> more portable and avoids the need to license additional > >>>>>>>> libraries. > >>>>>>>> > >>>>>>>> Writing a simple command line option parser isn't especially > >>>>>>>> difficult > >>>>>>>> or burdensome, anyway. > >>>>>>>> > >>>>>>>> --Chris > >>> > >>> _______________________________________________ > >>> sword-devel mailing list: [email protected] > >>> http://www.crosswire.org/mailman/listinfo/sword-devel > >>> Instructions to unsubscribe/change your settings at above page > >> > >> _______________________________________________ > >> sword-devel mailing list: [email protected] > >> http://www.crosswire.org/mailman/listinfo/sword-devel > >> Instructions to unsubscribe/change your settings at above page > > > >_______________________________________________ > >sword-devel mailing list: [email protected] > >http://www.crosswire.org/mailman/listinfo/sword-devel > >Instructions to unsubscribe/change your settings at above page > > _______________________________________________ > sword-devel mailing list: [email protected] > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
