James Carlson <[EMAIL PROTECTED]> wrote: > Joerg Schilling writes: > > > Despite having a 4 kiloline man page, star doesn't support the same > > > options as Solaris tar. It's not a drop-in compatible replacement, > > > and the interfaces in Solaris tar are listed as "Stable," meaning that > > > we promise not to break them until the next Major release (and perhaps > > > not then, if we can avoid it). > > > > Please try to inform yourself before writing obviously wrong claims. > > Please try to avoid ad-hominem attacks. They don't help you advance > any of your claims.
[snip] I did try to ignore your previous attacks, but...... I get the impression that you continue to send the same kind of attacks you did during the past days and as it seems that you still did not inform yourself correctly about what you try to answer, I give you the chance to start another try to reply to my previous mail. As I mentioned more than once, we need collaboration but this cannot happen if you send replies that look to me as if you only have the intention to discredit me. Funny enough, your claims do not apply even though they may look reasonable in the first second. ftp://ftp.berlios.de/pub/star/alpha/ Get a recent source of star and have a look at the documentation. Read e.g. the file STARvsGNUTAR and understand how option parsing is done. If you did understand how option parsing in star is done, you will find that your claims are void. Compare what getargs() allows you to do with the features you get with the Sun getopt() implementation. You will see that getopt() from the Solaris libc is not able to deal with a program that has many options while getargs() virtually allows an unlimited number of options. Getargs() also allows you to control the exact behavior of every option. Something you cannot do with other long option aware CLI parsers. But the way option parsing is done is unimportant here. We are talking about something completely different and it would help if you did stay with the topic which is discussing how to replace Sun's tar implementation by something more up to date and why Sun's tar did recently introduce new features that are based on deprecated POSIX.1-1988 features. Rethink the problem and try to understand which entity of what we are currently talking about, you may be able to control and which you can't control because you cannot force me to change the behavior of star. A behavior that has been stable for more than 20 years. Understand that there is a difference between star called as "star" and star called as "tar". You cannot change the CLI of "star" because this would cause incompatibility. You may discuss how future features of star will be implemented but then you would need to collaborate in the development of star. You may discuss the CLI and the behavior of the "sun tar" emulation of star. If you like to do this, please first have a look at star and really check for differences instead of condemning something wholesale without any proof. >From the content of your mails, I would guess that you will not observe differences between Sun tar and star's suntar emulation in your daily work (you claimed that you are happy with Sun tar and GNU tar, so you cannot do complex stuff with tar). If you find differences, read the Sun tar manual and verify whether the the behavior you expect is documented or if the man page would also allow the behavior of the "sun tar" emulation from star. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
