Stephen Hahn wrote: [CC:'ing [EMAIL PROTECTED] > * Roland Mainz <[EMAIL PROTECTED]> [2007-01-12 01:15]: > > Stephen Hahn wrote: > > > but I don't see any point to changing bldenv's default path > > > settings. Can you characterize the problem or problems you see > > > these changes fixing? > > > > If we want to enforce portable scripting via using the POSIX tools then > > the tools in the Makefiles and in the "bldenv" interactive environment > > should be identical. This is why I suggested to use > > /usr/xpg6/bin:/usr/xpg4/bin before /usr/bin to make sure we use thos > > features mandated by POSIX/XPG6 (I can make a patch for that after the > > ksh93 putback). > > That certainly makes sense as a conformance test.
... and improves portabilty (for example in a cross-compile environment etc.) and would be less painfull (e.g. part of such a cleanup could be to set SHELL=/usr/xpg4/bin/sh in the Makefiles to avoid that the engineers have to restrict themselves to plain bourne shell). > Let me make a different comment (but mostly on topic): I think it > would be very valuable to eliminate invocations of "old ksh" in the > various consolidations (changing them to ksh93 invocations), before > POSIXifying the build--that way all distributions would be happily > running on ksh93, and the ability of one to ship "old ksh" when others > cannot wouldn't be significant any longer... Ok... however I am little bit opposed to start a giant mindless "rampage" (or crusade) which converts all /usr/bin/ksh consumers which can't climb up a tree fast enougth to /usr/bin/ksh93 (e.g. AFAIK a plain switch won't add any "value"). But I think it may be a good idea to use ksh93 if some of the new features are used or if new stuff gets added to Solaris (offtopic: At this point it may even be usefull to compile all (or better: most) new packages with XPG6 flags (which would have some nice side-effects like that things like |popen()| would use /usr/xpg4/bin/sh instead of /sbin/sh, saving some complains about the plain bourne shell)). Possible examples include: - ksh93 has builtin localisation support. Instead of using /usr/bin/gettext scripts can put a $ in front of "..." string literals which makes these texts subject to localisation (see http://mail.opensolaris.org/pipermail/tools-discuss/2007-January/003209.html). The "tricky" part is that /usr/bin/gettext uses "text domains" to bundle message catalogs while ksh93 uses the script name to lookup the name of the catalog. This could be solved via plain softlinks (e.g. link "/usr/lib/locale/de_DE.UTF-8/LC_MESSAGES/myscript" to "/usr/lib/locale/de_DE.UTF-8/LC_MESSAGES/SUNW_OST_OSCMD.mo") but I guess such links would require an ARC case per softlink or patch set, generating lots of paperwork (I guess ARC doesn't give blanko permissions away, right ? :-) ... and we have to ask the i18n/l10n people whether they approve such changes in general before starting such a work) ... ;-( - Use ksh93 builtin commands. The advantage would be better performance since builtins do not |fork()|. The problem is that some of the builtins are disabled by default (per PSARC/2006/550) because they implement strict POSIX behaviour, making them compatible to the versions in /usr/xpg6/bin/+/usr/xpg4/bin/ but not to the pre-POSIX versions in /usr/bin/ (the "workaround" for Solaris is to put /usr/xpg4/bin:/usr/bin in front of the ${PATH} used by these scripts and then enable the builtins). - Use ksh93 math support (which supports floating-point (and since ksh93s almost all of the C99 math functions are supported (as "inoffcial" easter-egg (not ARC'ed yet but still usefull)))) - Use associative arrays and string operators (which could be used to eliminate most of the basic (but still mind-melting) sed/awk one-line filter scripts (as described elsewhre this can deal with giant amount of data, not even limited by the 4GB barrier)) - Use the ksh93 "getopts" builtin (as side-effect things like "myscript --man", "myscript --usage" etc. would generate manualpage/usage-like output) which is significantly more powerfull than the plain /usr/bin/getopts - General-purpose bugfixing (for example the usage of $* in usr/src/cmd/cron/batch.xpg4.sh and usr/src/cmd/cron/batch.sh hurts my eyes... AFAIK this will result in "interesting" effects if one of the arguments contains a whitespace... ;-( (and the "batch" scripts are canidates for the /usr/bin/gettext&&getopts changes described above)). - Some commands like /usr/bin/at have switches to set a shell, e.g. "-c" for "csh", "-k" for "ksh93" etc. It may be nice to switch these tools from /usr/bin/ksh to /usr/bin/ksh93 with the same priority as the normal script conversions (offtopic: This reminds me that /usr/bin/at still ignores the primary gid of the caller and lacks a "-g" option to set the primary group... ;-( ... and... http://src.opensolaris.org/source/xref/loficc/crypto/usr/src/cmd/cron/cron.h#93 ... |UNAMESIZE| is too small... AFAIK utmpx now allows at least 32 characters (... and I stop here before I spend more time digging out more bugs...)) - [Insert more stuff here] > (Of course, such an effort could be started in parallel now, by anyone > following Roland and co.'s ksh93-integration work.) Basically it can only start after the putback to make sure /usr/bin/ksh93 is available. Right now we're discussing some other smaller roads we could take while the ksh93 putback is "baking" for one or two OS/Net releases until it's clear we didn't mess anything up (just to avoid Murphy's law...). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
