> > While I don't know that I'd go that far, I think > gawk is one of the (IMO all too few) > > examples of a really good GNU implementation: the > developers worked > > with the original awk developers (from what I've > read) to get clarification > > on a lot of compatibility issues. And gawk > doesn't fall over on long lines > > or huge numbers of fields per line like the other > implementations do. > > > > Is there any particular reason why gawk (named awk > or nawk) couldn't > > replace both /usr/xpg4/bin/awk and /usr/bin/nawk? > > You know, there is a world outside GNU. IMHO it is > better to look at > Linux, BSD, OSX and combine the best of all worlds in > one > implementation and add own innovations. This is what > Olga's proposal > (attached) is about. > It is better to have an Opensolaris community with > active development > in this area than putting us at the mercy of the GNU > teams.
If you look again at what I said, I'm not by any means a reflexive admirer of GNU utilities. Some of them are good, some not; the very inconsistency among them is one reason I'd never suggest favoring them all. However, gawk compares well in my experience to every other version of awk that I've used (which is more than just the various ones on Solaris). Way back when, I'd run twice into situations where patching failed because some of the lines in /var/sadm/install/contents (or maybe an individual pkginfo file, with info on all the patches applied to that package) were too long. Subsequent patches updated awk and/or nawk to handle longer lines, postponing a recurrence. But I'd gotten really frustrated by then, so I'd run a comparison of what they could handle. http://groups.google.com/group/comp.unix.solaris/msg/f920ecd9790ae334 Just as I wouldn't favor GNU versions of utilities automatically, if one of them is really outstanding, I wouldn't look down on it either. ( As for Mac OS X utilities, I'm not consistently impressed there either. A lot of their stuff is pretty old. Their SunRPC library routines for example are horrible (I ported rpc.rwalld, but it wasn't very pretty. I think I started with a BSD version, since it was pretty old, but even then seemed to expect newer, i.e. maybe SunOS 4.x vintage, RPC routines than what the Mac had. Starting with the Solaris version would've been nuts. Since Darwin is Mach+BSD, those of us more accustomed to SysV lineage find a lot missing. I ported Solaris getent and getconf to Mac OS X. The first, it didn't even have (had some really ugly native tool for command line name services retrievals). The second, it had, but it didn't have the -a option and didn't know about as many names as it maybe could have. Mac are pretty darn good at GUI and graphics and Objective C stuff, but their Unix command-line utilities are _not_ all that impressive IMO. Aside from the very nice GUI and associated libraries on the Mac, some of the few other things I miss from platforms other than Solaris? ISPF, PL/1, and the M204 database on MVS. The sheer coolness of Burroughs MCP and the architecture it ran on. Typed file handlers in Apollo Domain/OS (enabling such things as DSEE, the ancestor of Rational ClearCase). The ined editor on PC/IX (and AIX) - esp. one version that had the ability to manipulate files with an internal version history (like an SCCS file, but not compatible). And I'd love another look at the parsing code that PC/IX had for "attribute structure files" - text files with named stanzas containing name=value lists. That parsing code was _magic_; a state machine and a hex array to tell it what to do. Tiny enough to work on an 8086-based SysIII derivative, but elegant. ) As for "putting us at the mercy", that's just FUD. If something is good when adopted, but its upstream maintainers later neglect it or mess it up, someone (us, if needed) could always fork it. That's not desirable of course, more work involved. But it is the insurance that one isn't at anyone's mercy. The best open source version is the place to start, regardless of license or project, unless it's something stupid like a library that's been GPL'd rather than LGPL'd. I would expect that a top quality set of standards compliant utilities would not exclude an implementation simply for already being a member of the GNU collection. -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
