Peter Memishian wrote: > > > In that case I see no benefit from the changes being proposed and I > > > don't think this should be integrated. > > I agree.
Erm... did you see Darren's later comments ? > > If there is more to come that > > > will speed up nightly to a point where it is actually noticable (I > > > really doubt it some how) I'd like to see a least an overview of that. > > > > 1. Please read > > http://opensolaris.org/jive/thread.jspa?messageID=407842#407842 > > Who exactly is clamoring for ksh93 statements in the opensolaris.sh config > file? The point was that bldenv uses ksh93 and nightly still uses ksh88, e.g. both are out of sync and it may be _nice_ to use ksh93 as a common level. > > 2. With the retirement of SXCE and the switch to Indiana we will get the > > switch from ksh88 to ksh93 implicitly. However I would prefoer to do the > > switch _now_ in a controlled and tested way instead of running into > > problems like CR #6872747 ("nightly's total build time calculation is > > b0rked") repeatedly. > > Plenty of developers are already building using the existing nightly with > ksh93. Problems like the one you cite above are cosmetic and do not > interfere with development. Right... but like many other scripts "nightly" urgendly needs a cleanup. This is janitoral work which has been often described as "long overdue" in OS/Net, including the gatekeeping infrastructure... > On the other hand, large changes like what > you are ultimately proposing (not just with this first wad) are much more > likely to cause serious problems Devils-advocate question: Does that mean we should continue to use and promote obsolete, depreciated and potentially dangerous constructs and faulty error handling in scripts ? If "yes" - what is the justification for this ? > and as more obscure ksh93 incantations > get added, it will be increasingly hard for others to understand and fix > these problems. Which of the statements I've proposed are "obscure" ? The I/O cleanup mainly revolves around opening a handle to the log file&&other I/O targets and keep it open (instead of doing an |open()|, |stat()|, |lseek()|, |write()| for each single command redirection). That's even POSIX shell syntax. The 2nd example (e.g. concaternation of "egrep" pattern) in my previous email was array handling (using the ksh93 += operator to make the code more readable) - which is something students learn in the 1st semester of the informatics studium. I don't see how this should be hard, maybe except for someone who only wrote Bourne shell scripts and never looked at which features the korn shell (=ksh88) has... ;-/ > Our goal for nightly should be to make it simpler to understand, That's what I want to do, using the correct syntax and methods for the Korn shell language (or POSIX shell langauge, the difference barely matters in this case). > not to > rewrite it in a language few in our community have expertise in. Right... but I don't want to restrict myself to Bourne-like constructs - IMO the _minimum_ level should _now_ (in 2009) be the POSIX shell specification (and even that is now more than 15 years old) and AFAIK my proposal _barely_ goes beyond that... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
