On Wed, 2008-06-04 at 13:03 -0700, Maxim Sobolev wrote:
> Coleman Kane wrote:
> >> Where do we stop? Should we add long options to all
> >> /usr/bin utilities? Why stop at /usr/bin, let's add
> >> long options to /usr/sbin, /bin, /sbin, /rescue, etc.
> >>
> >
> > I'm sure if someone has some "add long options to /bin/cp, etc..."
> > patches, we can surely discuss them on this list as adults and respect
> > the decision to add new features without deprecating any existing
> > features, even if we won't be making use of those new features.
>
> Please don't. Idea to add "long" options to existing "short" ones in
> base system utilities is very short-sighted. It could look like a cool
> pet project for somebody learning how to use C ("gee, ma, look, I have
> made a huge improvement in FreeBSD cp(1) in less than 10 minutes of
> work"), but in the long run it will hurt us all since sooner or later
> you will find yourself struggling with scripts that don't work on
> release X just because it was created on release X+N and therefore uses
> those cool new long options.
>
> -Maxim
> It's probably premature to begin shooting that down. I merely picked "cp" as the first tool that came to mind which lives in /bin. Maybe I should have picked on /bin/pax or /usr/bin/lex instead, or something else with 20+ getopt args :P. My point was that it was pretty absurd to start treating this like it will turn into a giant mad party of getopt_long conversions. I don't really have the inclination to go out and add long options to any tool myself, because I have better things to do with my time. As I said earlier, I think it's a better policy to discuss this when the patch/commit comes along, and see what people's feelings are on the matter then. I don't think it is anybody's place at the moment (except maybe core@) to try and deter a committer from making what some feel is a beneficial change to software. Using your argument above about scripts written for release X+1 not working under release X means that the addition of "-a" to /bin/cp should also be reverted, as well as numerous other changes that have happened to CLI tools like ifconfig. There are probably at least 100-or-so different things that change with each .0 release, this is why you have those monstrous case statements in configure scripts. I don't see how it is fair to cherry-pick the getopt_long changes here for these reasons, and chastise someone who's doing good work. Let's just calm down a bit here on this, I seem to have counted at least 6 people (including myself) who either liked it or at least felt that it is up to flz to make that call. Only 2 specifically wanted the commit yanked, and 1 person stated that they didn't like it but didn't state if they wanted it yanked. That sounds like a pretty good start to the decision making process. Remember, this is supposed to be fun. -- Coleman Kane
signature.asc
Description: This is a digitally signed message part
