James Carlson wrote: > 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. > >> 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."
While I agree with you both I don't think this ARC review is the place to design the ksh93 language evolution. It is what it is, we can either choose to take it as it is or we can step back and do ksh93 what we did to ksh88 (abandon it basically). Or we can ask the upstream (who hang out here I believe) to take this on board and consider it. 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. -- Darren J Moffat
