On Tue, Mar 2, 2010 at 6:21 PM, Richard L. Hamilton <[email protected]> wrote: >> With the other non-standard changes being made to the >> default >> environment, I wonder if it is time to finally bite >> the bullet and merge >> some of the XPG4 and Sun commands -- some of the >> differences exist for >> some rather silly (IMO) semantic differences that >> portable code should >> not rely on. >> >> For example, rm differs in some very subtle ways >> about conflicts of -f >> and -i options, and handling of non-readable/writable >> directories. >> >> chown differs in the way symbolic links are followed >> in the presence of >> the -r flag. >> >> XPG4 awk is really just nawk. >> >> XPG4 grep has more flexible regular expression >> support (see -E and -F) >> >> who has slightly different default output for POSIX. >> >> XPG4 du is noisy by default on unreadable >> directories, and uses a space >> instead of a tab. >> >> I'm sure there are some others like this. >> >> I'm just thinking, isn't it time we just bit the >> bullet and told our >> users to start using the POSIX defaults, instead of >> continuing to supply >> the legacy compatibility stuff forever. >> >> It would save a little space, and maybe we could get >> rid of /usr/xpg4/bin ? >> > > 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. Look at the success story of the ksh93 integration effort - maybe we can duplicate it for the POSIX user land, too. ---------- Forwarded message ---------- From: ольга крыжановская <[email protected]> Date: 2010/3/1 Subject: [ksh93-integration-discuss] [DRAFT] POSIX utility community Group Proposal To: Shells discussion <[email protected]> Cc: Korn Shell 93 integration/migration project discussion <[email protected]>, Michelle Olson <[email protected]>, Tim Marsland <[email protected]>, [email protected], David Comay <[email protected]> Please review the "POSIX utility community Group Proposal" below until Tuesday 18:00h MEST and send feedback to <[email protected]>. I will send out the revised proposal Tuesday 19.00h MEST. Olga ========================================= POSIX utility community Group Proposal Summary ----------------------------------------------------------------- The following is a proposal for the creation of an OpenSolaris POSIX utility community group that focuses on long-term innovation, enhancement, development, testing and maintainance of the basic POSIX commands and utilities in Solaris. Background ----------------------------------------------------------------- Right now, the OpenSolaris userland environment, specifically the POSIX-mandated commands and utilities, lacks a dedicated community which can guide its progressive evolution. This has a few unfortunate side effects: there is no *consistent* and modern API, there's no attention paid to how user-friendly the utilities are (it's been lamented that Solaris's userland is actively *hostile* to converts), there's been no real innovation in the Solaris userland for many years (except unconditionally using GNU coreutils as replacement instead of creating own *innovations* and focusing on the traditional strength of Solaris such as API stability, good internationalisation, performance, good testing, etc.), and there are no feedback loops or *joint* development with other vendors. As a result, this lack of manpower in the form of a dedicated community has resulted in a splintering of userland maintenance, alienating customers who rely on traditional Solaris features (like API stability, internationalisation, performance, ...) and general frustration with the userland (for example, stealing from GNU coreutils and putting their utilities in the front of the $PATH and relegating "standard" tools to demeaning locations such as /usr/has/bin). Thus far, without manpower and a community, no one is taking the responsibility to innovate and improve the utilities, following a strategic plan for the environment as a whole rather than a piecemeal approach for whatever utility is "broken today." Focus and Goals ----------------------------------------------------------------- The POSIX commands community's goal is to own, enhance, develop and maintain the POSIX commands in (Open-)Solaris. We discuss POSIX commands-specific topics here. Users can ask questions and report problems about the POSIX commands of (Open-)Solaris. The community work together to answer the questions, fix bugs, implement enhancements and work with the Austin Group to add new features to the next version of the POSIX standard. There are several projects&topics in the plan: - Implement bug fixes - Implement common BSD and GNU features based on the AT&T AST code base (the basis for this already exists with the ksh93-integration project) assuming they do not conflict with the POSIX standard (we will *not* break the POSIX standard in *any* case) Standard mode of operation is to implement missing features one-by-one if they are requested (or useful) and the ARC stability is set to "uncommitted" unless more than two implementations out of { AST, *BSD, GNU, MacOSX } implement them - in that case promotion to "committed" should be done and a proposal for inclusion into the next POSIX standard be made. - Invite other operating systems and vendors to partake in the projects and community (i.e. AT&T (AST), Apple (busybox) etc.) - Implement own test suite, preferably one test suite module per bug id - Improve performance - Improve portability of the code base - Improve maintainability of the code base - Improve observability (e.g. Dtrace) - Make the code base 64bit clean - Strengthen the POSIX conformance - Strengthen the i18n (multibyte) support - <...insert more goals...> Initial projects include: - ksh93-integration project - shell project - busybox (POSIX core) development project - shxml (XML shell API) development project - POSIX utility modernisation The community will own the following commands and have the sole responsibility to change them (note that many of these commands are actually shell special builtins and are only exposed in the fileystem for standard conformance reasons): /usr/bin/alias /usr/bin/at /usr/bin/awk /usr/bin/basename /usr/bin/batch /usr/bin/bc /usr/bin/bg /usr/bin/cat /usr/bin/cd /usr/bin/chgrp /usr/bin/chmod /usr/bin/chown /usr/bin/cmp /usr/bin/comm /usr/bin/command /usr/bin/cp /usr/bin/crontab /usr/bin/ctags /usr/bin/cut /usr/bin/date /usr/bin/dc /usr/bin/df /usr/bin/dirname /usr/bin/du /usr/bin/ed /usr/bin/edit /usr/bin/egrep /usr/bin/env /usr/bin/ex /usr/bin/expr /usr/bin/fc /usr/bin/fg /usr/bin/fgrep /usr/bin/file /usr/bin/find /usr/bin/fmt /usr/bin/fold /usr/bin/getconf /usr/bin/getopts /usr/bin/grep /usr/bin/hash /usr/bin/head /usr/bin/id /usr/bin/ipcs /usr/bin/jobs /usr/bin/join /usr/bin/kill /usr/bin/ln /usr/bin/logname /usr/bin/ls /usr/bin/mkdir /usr/bin/mkfifo /usr/bin/more /usr/bin/mv /usr/bin/nice /usr/bin/nl /usr/bin/nohup /usr/bin/od /usr/bin/paste /usr/bin/pathchk /usr/bin/pax /usr/bin/pr /usr/bin/printf /usr/bin/read /usr/bin/rev /usr/bin/rm /usr/bin/rmdir /usr/bin/sed /usr/bin/sh /usr/bin/sort /usr/bin/stty /usr/bin/sum /usr/bin/sync /usr/bin/tail /usr/bin/tee /usr/bin/test /usr/bin/tr /usr/bin/tty /usr/bin/type /usr/bin/ulimit /usr/bin/umask /usr/bin/unalias /usr/bin/uname /usr/bin/uniq /usr/bin/vedit /usr/bin/vi /usr/bin/view /usr/bin/wait /usr/bin/wc /usr/bin/who /usr/bin/xargs /usr/xpg4/bin/* /usr/xpg6/bin/* <CHECK if these are a) all commands covered by POSIX and whether b) all commands listed here are defined by POSIX> The community will *NOT* handle any commands outside this scope (i.e. the scope of this community is *STRICTLY* defined by the POSIX standard). Leadership ----------------------------------------------------------------- There will be core contributors and leaders to make decisions related to POSIX commands community, including creating new projects, maintaining existing projects. Core Contributors who are nominating the community * Don Cragun * April Chin * Roland Mainz * Olga Kryzhanovska Initial core contributors will be: * April Chin * Roland Mainz * Matt Lewandowsky * David Korn * Glenn Fowler * Don Cragun * Irek Szczesniak * Knut Reinert * Olga Kryzhanovska * Jennifer Pioch * Wendy Phillips * Norm Jacobs * Basabi Bhattacharya * Craig Mohrman * Kenjiro Tsuji * Carol Fields * Robbin Kawabata * Kristin Amundsen * Mike Light <check whether Nico, James, Ralf and Moinak have any interest> -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ [email protected] \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` -- Irek _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
