Jason King wrote:
I cringe every time I hear that justification trotted out. If that is
the end goal, we can fix things much easier and quicker -- stop all
work on Solaris immediately, and ship Linux. That is the only way
you'll have achieve Linux compatibility.
The goal should be to have the best userland out there -- whether it's
the current Solaris utility, a GNU utility, BSD, AST, etc.
The two justifications that I've seen for this change are:
1. It allows fractional seconds.
2. It allows us "to re-use existing, maintained code instead of
maintaining two seperate codelines (e.g. one in usr/src/cmd/sleep/ and
the AST/ksh93 "sleep" version) which have to be kept in sync all the time".
The first is presumably considered to be a good thing because it
increases compatibility with other OSs (e.g. Linux). However, on that
front the ksh93 sleep is not that much of an improvement, as although it
supports fractional seconds it doesn't support the 's', 'm', 'h' and 'd'
units that GNU sleep supports.
The second justification seems slightly flimsy - as others have pointed
out, the C implementation wasn't exactly huge and as this thread
illustrates, the ksh93 implementation has several problems.
The other factor that hasn't been discussed at all is that the second
justification for this change is diametrically opposed to the
justification behind the changes introduced by the following bugs:
http://bugs.opensolaris.org/view_bug.do?bug_id=5019961
http://bugs.opensolaris.org/view_bug.do?bug_id=6210677
Are those changes going to be undone by rewriting /bin/true, /bin/false,
/bin/basename, /bin/dirname (and others) in ksh93? If so, at which
point did the justification for 5019961 and 6210677 become invalid?
Being different isn't a bad thing -- IF there is a definite advantage.
I don't see a lot of people complaining because of differences with
OS X or the BSDs vs. Linux.
Actually, that's just about the most frequent complaint that we get.
I'm also unclear at which point ksh93 was elevated to the level of primacy
that this change implies. It appears that this change is making Solaris
less rather than more shell-agnostic, and I'm failing to understand why that
is considered to be a good thing.
Bugs aside, a binary is a binary. If /bin/sleep or /bin/printf happen
to be symlinks to ksh93, how does this prevent you from doing anything
in csh, zsh, bash, etc?
The new /bin/sleep isn't a symlink to ksh93, it is a shell script.
It's a bit like saying Solaris is not
language (programming) agnostic because libc is the primary stable API
for developers. Yeah a lot of the stuff is written in C -- and a lot
of the system stuff is written as sh or ksh scripts. It doesn't
prevent anyone from using csh, zsh, ruby, python, java, C++, Ada,
Fortran, or even Cobol on Solaris.
The interface provided by libc is defined by the OS calling convention
and the system linker, not the language it is written in. The interface
provided by shell-level commands is defined by the command-line
arguments they accept, not the language they are written in. What I'm
pointing out is that this change makes the shell-level interface to
sleep be the same as the ksh93 implementation. If a shell doesn't
provide a sleep builtin the system implementation will now have ksh93
semantics, hence the comment about the elevation of ksh93 to a new level
of primacy.
However I haven't seen any justification as to why the ksh93-style
interface is to be preferred over any of the other possible interfaces.
--
Alan Burlison
--
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
