Jason King wrote:
> On Tue, Aug 18, 2009 at 8:09 PM, Roland Mainz<roland.ma...@nrubsig.org> wrote:
> > Peter Memishian wrote:
[snip]
> >> 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).
Yes... the script lacks even basic "prechecks" to test whether there is
really a source directory, whether all variables and applications etc.
are there (the build will later fail in such cases but IMO it may be
nice to catch this _before_ wasting several CPU-hours) nor does check
whether things internally work correctly (e.g. most error codes from
commands are simply ignored).
[snip]
> > 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?
Yes, there are. That was the main drive behind doing an all-in-one
cleanup attempt - I don't have time to do "nitpicking", do the bugfixing
on an one-per-case or one-per-bug or write a giant document which
outlines all possible bugs and describe there consequences so I simply
crawled over the script and just pick as much issues I could find and
fixed them. Unfortunately those patches rotted away because we had so
many discussions with "why do you do that ?", "why did you change that
?", "why is this important ?" etc.
> 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?
Scoping is one issue. The "optional" nature of variable declaration,
declaring+using them with wrong datatypes (e.g. strings vs. integers,
using string operators to match integers, use hacks to archive
arithemtric operations or plain abuse of arithemtric expressions
(including return codes)) is another issue. AFAIK the script will simply
break down in subtle ways with the switch from SXCE to OpenSolaris and I
hoped to fix the issues _before_ we do the switch...
> 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?
No, it was never formally approved because if you ask 100 people about
shell scripting coding standards you'll get 250 answers. Even worse: If
many people can't agree you usually get the minimum set of rules based
on the least-capable shell available (which damages the script quality
if such rules are enforced for more capable shell interpreters (for
example the idea to enforce rules from the Bourne shell age on shell
interpreters build along the lines of the POSIX shell standard)).
> 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.
Umpf... "cstyle" will _not_ help - the problem is not how the code is
formatted, the problem is how the code uses the shell capabilities. We
need something like a shell lint, not something which enforces rules
like line length limits.
----
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
