April Chin wrote:
> > Attached is a patch ("ksh93_solaris_builtins001.diff.txt") which deals
> > with the ksh93 builtins and their compatibilty to the Solaris versions.
> > The patch splits the ksh93 builtins into three categories:
> > 1. Builtins which conform to XPG4 are prefixed with /usr/xpg4/bin/
> > (which means they're picked if ${PATH} contains /usr/xpg4/bin and this
> > ${PATH}-element is searched for this specfic command
> > )
> > 2. Builtins which are compatible to the native Solaris commands are
> > prefixed with /usr/bin/ AND /bin/ (since /bin is a link to ./usr/bin,
> > this is needed as scripts sometimes use /bin or /usr/bin or both in
> > their ${PATH})
> > 3. All ksh93 builtins are prefixed with /usr/ast/bin/ (see
> >
> http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-May/000345.
> html
> > why /usr/ast/bin was selected) to make them available this way
>
> I've been pondering the below approach to the builtins.
> Although I believe we can add builtins which are bound to
> some non-standard pathname, such as /usr/ast/bin or /opt/ast/bin, I think
> we need to be extra careful about adding builtins which duplicate
> Solaris command names and binding them to standard Solaris directories,
> such as /usr/bin, /bin, or /usr/xpg4/bin.
I agree... I did lots of thinking before I created the patch I've
posted...
> By adding these bindings, ksh93 users who have these binding
> pathnames on their path will automatically be using the AST libcmd
> builtin version of that command, rather than the Solaris binary.
Yes, but only if they use the command by it's plain name - if they use
the full path (e.g. "sleep" vs. "/usr/bin/sleep") the non-builtin
version will be used.
> I can think of one case (and I'm not saying to fix this) where
> the head command from AST libcmd behaves differently
> than Solaris head. Without careful analysis of each command, I don't
> think we can safely replace them for ksh93 users.
>
> In the below patch, there are 36 builtins bound to pathnames which
> duplicate Solaris commands. Of those 36, 21 builtins are bound
> to /usr/bin, /bin, and/or /usr/xpg4/bin.
>
> The original list of default /bin-bound builtins in ksh93 is only the
> below 13,
>
> /bin/basename
> /bin/cat
> /bin/chmod
> /bin/cmp
> /bin/cut
> /bin/dirname
> /bin/head
> /bin/logname
> /bin/mkdir
> /bin/uname
> /bin/wc
There are some problems with the current list:
1. It is generated automatically based on simple tests ("simple" = no
comparisation for Solaris-specifics is done)
2. The list does not include the fact that /usr/bin and /bin are the
same (soft-linked). Only if /bin is in ${PATH} they are used and not if
only /usr/bin is in ${PATH} (e.g. IMO this is inconsistent)
3. The list is simply wrong, for example ksh93's "basename" builtin
implements the POSIX standard while in Solaris's /bin/basename the
"suffix" parameter is processed via "expr" (this is non-standard
behaviour while ksh93's "basename" buildin exactly implements the POSIX
standard (and is therefore listed as /usr/xpg4/bin/basename)).
> so I'm also not sure if there is good reason (other than adding
> AST versions of commands into ksh93, for those who want them)
> for expanding the list to 36, as far as what a typical ksh93 user might
> expect.
Actually I posted the patch for inclusion into the ksh93 distribution so
on Solaris both the normal version and the one shipped with Solaris
would be the same...
> But I think the expanded set of builtins is acceptable if they are
> not bound to the standard Solaris paths.
If you look at the list you may see that I invested some time thinking
about the placement. The only commands which are in /usr/bin (and /bin)
are:
-- snip --
cat
chmod
chown
head
mkdir
rmdir
sleep
tee
uniq
wc
-- snip --
These are - with the exception of "chmod" and "sleep" - very simple
programs - it's very hard to imagine to have bugs in them after they've
been part of the AST distribution for several years (my imagination
simply fails how - for example - "/bin/mkdir" could be broken without
being obvious in the source when comparing the two verions (AST vs.
Solaris)). "sleep" is an exception becase it has an extended
functionality over /usr/bin/sleep because it accepts fractions of a
second as input - and "chmod" was extended to support ACLs which is not
part of the AST codebase (yet).
Then there are the builtins for /usr/xpg4/bin/:
-- snip --
basename
chgrp
chown
cp
date
expr
id
ln
mv
rm
stty
tail
-- snip --
These are POSIX/XPG4 implementations of these commands - like the
commands in /usr/xpg4/bin are implementations of XPG4, too.
The question is now: What do we want ? Do we want compatibility to the
XPG4 standard or compatibilty to the XPG4 implementation in Solaris ?
IMO the first choice sounds much better. If there is a difference
between the builtin commands and those in /usr/xpg4/bin then this is
likely a bug in one of the implementations and should be fixed. Or
scripts depend on the Solaris XPG4 implementation, resulting in a
portabilty issue which should be addressed.
IMO the ksh93 builtins tagged with XPG4CMDLIST() in the my patch should
be left enabled (see below (bottom) about the first putback). If they
cause trouble then there is likely a (portabilty) problem somewhere
which needs to be addressed. And there are at least three ways to
quickly deploy workarounds so I don't think this is really an issue...
> Please remember that although these builtins will be in /usr/bin/ksh93 only,
> the eventual plan is to replace /usr/bin/ksh and /usr/xpg4/bin/sh
> with ksh93. So when that happens, /usr/bin/ksh users and scripts will be
> switched to using some 21 new builtins instead of the Solaris commands.
> I can see having these builtins available as an option (if users add
> /usr/ast/bin to their paths), but not as a default (because users will
> already have /usr/bin on their paths).
>
> sleep is already a builtin in ksh93 without any pathname bindings,
> and the functionality is an extension of Solaris's sleep command,
> so I think it is safe to just leave sleep as a builtin
> with no pathname bindings.
Actually I was thinking about getting rid of the Solaris version of
/usr/bin/sleep at all and replace it with the AST version (which simply
wrapps a |main()| function around |b_sleep()|) so both versions would be
identical (that's why my patch adds /bin/sleep and /usr/bin/sleep).
> My recommendation is that ksh93 initially include these builtins
> bound only to /usr/ast/bin (or some other pathname which is not
> standard for Solaris),
IMHO we should use /usr/ast/bin/ as used in the patch.
> and we revisit adding other binding after ksh93
> is integrated.
UMpf... I am not very happy with that... basically we're throwing away a
HUGE performace advantage (for example the builtins are one of the
reasons why ksh93 can outperform perl in many scripting cases) because
we fear the mythical "this-may-be-a-problem-someday"-monster... ;-(((
What about this: We disable the |XPG4CMDLIST()| macro in the patch for
now (e.g. ksh93r+) and only take those commands in /usr/bin/ and /bin as
builtins (I volunteer to crawl through the sources and compare them
against the Solaris versions).
Later (for ksh93s) we look again at the commands tagged with
|XPG4CMDLIST()| and enable them for all ksh93-based shells except
/usr/xpg4/bin/sh (which should exclusively use the /usr/bin/xpg4/bin
commands)
Would that be OK for you ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
