> > > 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.
So in other words, no one is clamoring for this. > > 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 ? We should change things if they cause real problems to developers, or if doing so would clearly reduce maintenance costs. > > 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 number of developers I know who know the specifics of "POSIX shell syntax" can be counted on one hand. Most ON developers are experts in C, not in ksh93 programming. > 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... ;-/ As I said, I am not so much concerned by your current changes as by the direction it sets for ever-more-obscure ksh93 changes. > 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... Sticking with ksh88 compatibility would be a fine middle-ground as far as I'm concerned: most ON developers know a reasonable subset of ksh88 and can maintain it. (I know that doesn't fit with your agenda.) -- meem _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
