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