On Tue, Aug 18, 2009 at 8:09 PM, Roland Mainz<roland.ma...@nrubsig.org> wrote:
> Peter Memishian wrote:
>> > > > 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.
>
> What exactly does "clamoring" mean ? Assuming it means "want" - as said
> it is usefull (e.g. take a look at the DMAKE_MAX_JOB "memory limiter" in
> one of my other emails) and basically what the switch from SXCE to
> Indiana will anyway do...
>
>> > > 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.
>
> 1. One of the real problems is that the coding style (OkOk, nightly is
> quite old and grew over time (and I think it was originally a Bourne
> shell script, right ?)) and code pieces of scripts like nightly.sh are
> used as "justification" (e.g. "nightly uses Bourne syntax/eval/no error
> handling/no quoting/<insert-more-horrible-scripting-things> - why should
> I use something else ?") to do similar things in new scripts, e.g. some
> kind of "cargo cult scripting" (also known as CPP-programming
> ("CPP"==copy, paste, pray).
Does the current script have issues handling errors today? If so, I
would think that should be a bug and be addressed (or at the very
least, there should be something to indicate why not handling it is
ok).
> 2. Can we please agree that the usage of obsolete syntax and obsolete
> pre-POSIX features should be replaced with POSIX constructs (see below
> for "ksh88 vs. POSIX shell"), datatype abuse fixed (for example CR
> #6872747 ("nightly's total build time calculation is b0rked") is one of
> the bugs which could've been completely avoided long ago by just using
> "integer" and "printf") and that the script's I/O should be
> "streamlined" ? AFAIK this would cover most of the things I'd like to do
> with "nightly" ...
>
>> > > 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.
>
> I think this is not true. The POSIX shell syntax is a derived subset of
> the the ksh88 shell syntax with minor variations (e.g. functions
> declared with "foo()" do not have a seperate scope while ksh88 provided
> a seperate scope etc.) which are usually hard to find (anyone care about
> the difference that ksh88 treats "010" as decimal value "10" while POSIX
> uses decimal value "8" ?) and therefore I think most people working on
> OS/Net should be familar with it... :-)
>
>> Most ON developers are experts in C,
>> not in ksh93 programming.
>
> Erm... see below for the list of exceptions... but I have no intention
> to mutate this script into something which will toast brains immediately
> when people read it.
>
>> > 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.
>
> But which obscure changes do you mean ? I really don't want to use stuff
> like "types" (ksh93's version of object oriented classes&&interfaces),
> record-oriented pipes or something like that. Just plain POSIX shell
> syntax with (_maybe_) tiny extensions which are all AFAIK
> straightforward extensions of the standard (for example the [[ ]] test
> operator (which is in ksh88 but not POSIX (yet)), the += operator to add
> array elements, allowing "float" in arithemtric expressions, "builtin"
> to load builtin commands, extended regular expressions in matches (e.g.
> [[ $var = ~(E)hello.*world ]] (well, I can use extended ksh88
> patterns...but they will likely be a lot more unreadable than the
> familar egrep expressions... =:-) ) and using "redirect
> 4<>/foo/filename" instead of "exec 4<>/foo/filename" (because "exec"
> will terminate the shell interpreter immediately on |open()| failure
> while "redirect" allows to catch errors in the script) )).
>
>> > 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 would prefer to replace "ksh88" with "POSIX shell syntax" (since this
> syntax is hopefully well-known and ksh93 is fully POSIX-conformant)
>
>> (I know that doesn't fit with your agenda.)
>
> Groan... please see above... as said I don't want to turn the script
> into some object-oriented monstrosity or something worse. That's not on
> my agenda. Neither am I interested in "world domination" or something
> like that. My only interest is to get some janitor work done which is
> IMO urgendly needed...
Some questions that I have (I think some of these were hinted at, but
I think it'd be nice to have a more explicit answer)
Given that Opensolaris (the distro) is the future and SXCE is going
away, ISTR that ksh88 would then also be going away as a consequence.
With that in mind,
1. Are there bugs when nightly is run using ksh93 vs ksh88?
2. Are there changes between ksh93 vs ksh88 that might introduce
subtle bugs with the current coding style?It sounds like variable
scoping might be one possible type of bug, but I'm not sure I
understood what you meant when you mentioned it?
3. Is there any actual accepted sh/ksh coding standards like there are
with C on ON? -- I know you had proposed a set, but has that been
adopted, or is there any previous document that your proposal is meant
to replace? It seems like there is at least some informal ones (based
on my own experiences), but it wasn't clear if this is actually
formalized like the cstyle checks in ON.
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
