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...
> 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.
> 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 --
> 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".
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
