> Date: Thu, 22 Jun 2006 05:38:39 +0200
> From: Roland Mainz <roland.mainz at nrubsig.org>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: April Chin <April.Chin at eng.sun.com>, 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: rfrBhvZ-8eYoLh+AhAThmobsCLPRC+7ODPe9z0p8FfZv8RgDJA6hQ0 at t-dialin.net
> X-TOI-MSGID: e3a50952-62f9-443a-a656-828c8d7a3f8b
>
> April Chin wrote:
> > > 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.
>
> That's included in my patch already...
Okay, sounds good. We'll want to document these
>
> > 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?
>
> See David Korn's posting on builtins. Basically when ${PATH} is searched
> for a command which element of the path gets checked whether there are
> builtins which used be used instead. They do not need to be exactly the
> same code, they just need to be compatible in functionality.
>
> > 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.
>
> Erm, no. Builtins prefixed with a path (for example
> /usr/xpg4/bin/basename) will only replace the on-disk command when the
> shell searches the ${PATH} element "/usr/xpg4/bin". If ${PATH} does not
> contain "/usr/xpg4/bin" as element or another directory listed in
> ${PATH} contains a "basename" command before "/usr/xpg4/bin" is searched
> by the shell command lookup then this binary will be used instead of the
> builtin.
Ah, okay, sorry--for some reason I forgot that this is how it works...
For standards-conforming commands, the binary in /usr/bin on Solaris may be
the standards-conforming version if there is no /usr/xpg4/bin or /usr/xpg6/bin
command. In this case, a ksh93 builtin bound to
/usr/bin will override the Solaris /usr/bin version.
>
> > Although users
> > can call the binaries using the full pathnames, they should expect
> > to get the conforming behavior without doing this.
>
> They will get that behavour as they requested... don't worry... :-)
>
> > 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>
>
> Erm... what do you mean here ? "-m" is supported:
> -- snip --
> mkdir
> --help
>
> Usage: mkdir [ options ] directory ...
> OPTIONS
> -m, --mode=mode Set the mode of created directories to mode. mode is
> symbolic or octal mode as in chmod(1). Relative modes assume
> an initial mode of a=rwx.
> -p, --parents Ensure that each given directory exists. Create any
> missing parent directories for each argument. Parent
> directories default to the umask modified by u+wx. Do
> not consider an argument directory that already exists to
> be an error.
> -- snip --
Yes, -m is supported, but in this case, the builtin behavior is different
from Solaris.
In the below, /usr/bin/mkdir is the Solaris version; plain mkdir is the
ksh93 builtin. The below case is similar to a test case in the
VSC standards test suite:
$ umask 0777
$ /usr/bin/mkdir -m =rx d1
$ ls -ld d1
d--------- 2 chin staff 512 Jun 22 2006 d1
$ mkdir -m =rx d2
$ ls -ld d2
dr-xr-xr-x 2 chin staff 512 Jun 22 2006 d2
>
> > 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.
>
> Yes, but as I said it's just one line to disable in the list... :-)
>
> > 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?
>
> See David Korn's posting, too...
>
> > 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,
>
> ... that's not correct, see below...
>
> > which would not be what they
> > expected.
>
> Erm, no. Builtin commands which have a path prefix are used at the point
> when the shell searched the matching element in ${PATH}. If
> "/usr/gnu/bin" is in front of "/bin" (e.g. PATH=/usr/gnu/bin:/bin) then
> the GNU version will be used if there is any in "/usr/gnu/bin".
Yes, you're right, this is not a problem--thanks for correcting
of my misunderstanding.
>
> ----
>
> Bye,
> Roland
>
> --
> __ . . __
> (o.\ \/ /.o) roland.mainz at nrubsig.org
> \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
> /O /==\ O\ TEL +49 641 7950090
> (;O/ \/ \O;)
