> X-Original-To: ksh93-integration-discuss at opensolaris.org > Delivered-To: ksh93-integration-discuss at opensolaris.org > Date: Fri, 16 Jun 2006 11:15:37 +0200 > From: Roland Mainz <roland.mainz at nrubsig.org> > X-Accept-Language: en > MIME-Version: 1.0 > To: Korn Shell 93 integration/migration project discussion <ksh93-integration-discuss at opensolaris.org> > Subject: Re: [ksh93-integration-discuss] ksh93 builtins in Solaris -thepatch... > Content-Transfer-Encoding: 7bit > X-ID: ZYP4tmZD8eCj-bFphD98qSyqsJ7CPV548wNFuxA99ElWJWFKikGbkS at t-dialin.net > X-TOI-MSGID: 5e588719-31df-447d-b10c-21645d7b30aa > X-BeenThere: ksh93-integration-discuss at opensolaris.org > X-Mailman-Version: 2.1.4 > List-Id: Korn Shell 93 integration/migration project discussion <ksh93-integration-discuss.opensolaris.org> > List-Unsubscribe: <http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss>, <mailto:ksh93-integration-discuss-request at opensolaris.org?subject=unsubscribe> > List-Archive: <http://mail.opensolaris.org/pipermail/ksh93-integration-discuss> > List-Post: <mailto:ksh93-integration-discuss at opensolaris.org> > List-Help: <mailto:ksh93-integration-discuss-request at opensolaris.org?subject=help> > List-Subscribe: <http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss>, <mailto:ksh93-integration-discuss-request at opensolaris.org?subject=subscribe> > > Casper.Dik at Sun.COM wrote: > > >If I understood correctly, the /usr/bin (and /bin) builtins are > > >compatible with the Solaris version. If that's true, then I think this > > >is fine from an interface point of view. > > > > > >The fact that we need to crawl through code is a bad sign, though. > > >Duplicate code introduces the possibility of making a change in one > > >place and not the other, leading to bugs. It would be better to > > >refactor, so that ksh93 and the Solaris binary can share common code. > > > > Seconded. I feel very uncomfortable about the whole "plain > > commands as builtins" issue. Unless they are refactored into > > common apps, > > What do you mean with "are refactored into common apps" ? You mean that > both should share the same souce ? That's easy from the engineering part > (for example see > http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-June/000405 .html). > The hard part seems to be to hunt down a matching lawyer at Sun and let > him/her sign the mythical contribution form. > > > I'd be in favour of not enabling any of the builtins > > except those which commonly are (test, echo, [ ). Correctness trumps > > performance. > > In theory, yes... that's why I accepted the massace of the builtins > tagged with XPG4() for now. > Finally we're taking about less than two hand full of builtins with a > tiny codebase (which passes the SuSE testsuites and I've crawled through > the sources, too) and IMO it's an overkill to disable them all. Or did > you find any specific issue in the ksh93/AST implementation of these > commands ?
Rather than disabling, we could initially include the commands and bind them to /usr/ast/bin only. Users who want the performance and the AST versions of the commands can opt in by adding /usr/ast/bin to their path. This makes the AT&T commands easily accessible, without affecting existing Solaris usage of these commands on ksh. I think my assumption about the binding of builtins to pathnames is that the builtin command you are getting which bound to say, /bin, is supposed to be the same as the binary command in /bin. Was this the intention, even though the way it works is that the builtin gets executed even if the pathname it's bound to may not exist? Please remember that all of the ten commands being proposed as builtins bound to /usr/bin and /bin are listed as standards conforming. Per our standards(5) manpage, users set up their paths to get SUSv2 or SUSv3-conforming behavior--these paths will include /usr/xpg4/bin ahead of /usr/bin. However, with these builtins bound to /usr/bin, users would get the builtin instead of the conforming /usr/xpg4/bin or /usr/bin binary. Although users can call the binaries using the full pathnames, they should expect to get the conforming behavior without doing this. I have not checked any others, but AST mkdir does have some non-standard behavior that differs from Solaris /usr/bin/mkdir-- it does not take umask into account for mkdir -m <mode> <dir> Also, we know that AT&T chmod does not include the ACL code and we don't yet know that we can contribute this CDDL code to AT&T. The whole concept of builtins being bound to a pathname is fairly new to me, and it may be new for others. Or maybe I was just ignorant. :-) Do other shells have this construct? It may not be as much of an issue for a separate /usr/bin/ksh93 as it would be for ksh93 as /usr/bin/ksh. Also, it looks like there is a new project out on Open Solaris that is proposing new /usr/gnu/bin commands. See http://www.opensolaris.org/os/community/gnu_solaris/ The idea is that a user would put /usr/gnu/bin to their path first to get the "GNU personality". But what if they were using ksh93? If there were a GNU command that was the same name as a ksh93 builtin command bound to /usr/bin and /bin, and they had /usr/gnu/bin followed by /usr/bin or /bin on their path, they would instead get the AT&T command, which would not be what they expected. Thanks, April > > ---- > > Bye, > Roland > > -- > __ . . __ > (o.\ \/ /.o) roland.mainz at nrubsig.org > \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer > /O /==\ O\ TEL +49 641 7950090 > (;O/ \/ \O;) > _______________________________________________ > ksh93-integration-discuss mailing list > ksh93-integration-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
