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 --
