[ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008]
James Carlson wrote: [sorry, this one was stuck&&forgotten in my Drafts/-folder] > Garrett D'Amore writes: > > Have the upstream providers given thought to dealing with changes like > > this and their impact on already-deployed scripts? (Maybe there aren't > > any that we care about yet, since our ksh93 is still so new.) > > We've already had such problems. See CR 6667990 for one such > accident; you can't call your local function "start" and upgrade > safely from Sun's old ksh88 to ksh93. 1. AFAIK the "quagga" builtin has problem with the ksh(88|93) shell _alias_ called "stop" 2. The issue is caused by the switch from Bourne shell to ksh, not by ksh93 itself. ksh88 already had the "stop" alias: -- snip -- $ /usr/bin/ksh -c 'alias' | fgrep "stop" stop='kill -STOP' -- snip -- ... and other shells have the same problem. And the trouble is that "stop" is an shell "alias" which pretty much overrides anything else (as a future countermeasure we'll get "shlint" at some point (once "shcomp" is in the tree) to check for such common dragon-filled pits in the future (in the meantime you can run your script against $ shcomp -n /dev/null # ...)). > > I'm concerned, going forward, as ksh93 syntax becomes more prevalent, > > that bringing in changes like the above may have unintended consequences > > in scripts or even ON delivered components, which we cannot easily find > > or test. > > This probably isn't a good place to design a solution, but I share the > sense of unease. It puts script writers on shaky ground if they can't > either specify a known environment or predict what's "safe." Umpf... IMO "safe" is what's described in the POSIX shell standard and http://www.opensolaris.org/os/project/shell/shellstyle/ (that's why I wrote that document...). Bye, Roland P.S.: Setting Reply-To: to ksh93-integration-discuss at opensolaris.org to get this off he ARC list... -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008]
Roland Mainz writes: > 2. The issue is caused by the switch from Bourne shell to ksh, not by > ksh93 itself. ksh88 already had the "stop" alias: Correct. That's exactly the accident. > Umpf... IMO "safe" is what's described in the POSIX shell standard and > http://www.opensolaris.org/os/project/shell/shellstyle/ (that's why I > wrote that document...). If it's only C/C++/Java that are the sources of new keywords (outside of the existing shell standards), then I guess I can agree that it's now predictable. It was the importation of keywords from some other source that was the problem I was referring to: it puts an unconstrained burden on the script writer if keywords can be borrowed in the future from just arbitrary sources. (I guess I'm still a little fuzzy on the issue, as "C/C++/Java" aren't precise standards references, but I'll just presume that readers know what you mean here.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008]
Roland Mainz wrote: > > Did you thing about the fact that ksh93 is _really_ big and that people who > > like to use OpenSolaris in embedded environments probably cannot use ksh93 > > for > > this reason? > > Erm... the issue is the other way around - the use of builtin commands > enables ksh93 to work much faster and with less memory (since you can > avoid awk/sed/tr/etc. completely and even avoid temporary files for You would need to prove this on an embedded system. I am not convinced at all. If you run huge shell scripts like "configure", I would expect the ksh to be faster but for the scripts that Solaris uses for startup, things look much different. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
[ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008]
I'm sure we can have this discussion off-ARC size can be levereged when properly engineered (properly == transparent to the user save space/time measurements) a few years back we did a real world test on a handheld with ksh+libshell.so+libcmd.so+libast.so+libcmd-main-stubs where libcmd-main-stubs were all hard links to one main a.out for all ast libcmd command and the disk footprint was smaller than the equivalent set of /bin utilities, and, once the .so's were pulled in by the first exec, ksh startup time was in the noise, and set up to use the builtin libcmd commands directly enabled the usual fork/exec-less speedups in that off-ARC discussion we can resurrect real numbers based on scripts you deem typical for embedded systems -- Glenn Fowler -- AT&T Research, Florham Park NJ -- On Fri, 30 May 2008 13:55:04 +0200 Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) wrote: > Roland Mainz wrote: > > > Did you thing about the fact that ksh93 is _really_ big and that people > > > who > > > like to use OpenSolaris in embedded environments probably cannot use > > > ksh93 for > > > this reason? > > > > Erm... the issue is the other way around - the use of builtin commands > > enables ksh93 to work much faster and with less memory (since you can > > avoid awk/sed/tr/etc. completely and even avoid temporary files for > You would need to prove this on an embedded system. I am not convinced at all. > If you run huge shell scripts like "configure", I would expect the ksh to be > faster but for the scripts that Solaris uses for startup, things look much > different.
[ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008]
Joerg Schilling wrote: >You would need to prove this on an embedded system. I am not convinced at all. Interesing discussion - But not as part of this case. A future appliance/embedded OpenSolaris project is free (nay, almost expected) to make its own choices as to which utilities it will use. Almost certainly, it will not use the same choices as do the laptop or bigiron configurations we are building here. -John
[ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008]
Joerg Schilling wrote: > James Carlson wrote: > > Darren J Moffat writes: > > > While it is ksh93 I don't think any of this really matters that much > > > because you have to explicitly ask for ksh93. On the other hand if this > > > same implementation was exporting this same functionality by default > > > when it was used as the implementation of /bin/sh I would feel very > > > differently. This still isn't the case to make ksh93 /usr/bin/ksh which > > > is where I think this type of issue matters most. > > > > True enough, though, because of Indiana, we're already hacking our > > system scripts to comply with ksh93's differing requirements. > > Why? > > Did you thing about the fact that ksh93 is _really_ big and that people who > like to use OpenSolaris in embedded environments probably cannot use ksh93 for > this reason? Erm... the issue is the other way around - the use of builtin commands enables ksh93 to work much faster and with less memory (since you can avoid awk/sed/tr/etc. completely and even avoid temporary files for small things (e.g. stuff data into arrays, variable trees or plain string variables)) than using Bourne shell and lots of external commands (that's why we're (slowly) working on libbusybox.so.1, too). The startup time of ksh93 is highter than the Bourne shell (primarily because we do the i18n setup correctly and simply have more stuff to init at startup) - but that "price" is quickly paid-off by simply avoiding one single |fork()|+|exec()| sequence - beyond that ksh93 outperforms the Bourne shell, bash, zsh, dash etc. in all benchmarks (remeber David Korn had a slide about perforamce in his talk at the OpenSolaris May 2008 summit). --- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008]
John Plocher wrote: > I. Szczesniak wrote: > > It was always good practice to avoid C language keywords in shell > > scripts. Quoting the Opensolaris programming style guide: > > Do not use function names which are reserved keywords (or function > > names) in C/C++/JAVA or the POSIX shell standard (to avoid confusion > > and/or future changes/updates to the shell language). > > And that may be good enough to serve as the last word on this topic :-) Mhhh... while thinking about Irek's comment... ... can we do "recommendations" in an ARC case (not strict rules... more being "suggestions") ? Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344 FastTrack timeout 06/03/2008]
Roland Mainz wrote: > can we do "recommendations" in an ARC case (not strict rules... more > being "suggestions") ? Many times those comments are simply pointing out well known architectural requirements that may be unknown to the project teams. Other items are explicitly called out as TCR's (aka required changes), and many times such things are debated by the ARC members themselves. Still other items are such obvious pieces of good advice that the project team simply accepts them and incorporates them into an updated spec. Excluding the above, the rest of the discussion between the project team and the ARC members is usually advice. Sometimes it is obvious and good, other times it is off base and crap (but it is always free!) Good project teams tend to listen to this advice and cherry pick the most important. Inexperienced teams often misinterpret advice as being an absolute requirement, or utterings by an ARC member as being a formal requirement -John
