Casper.Dik at Sun.COM wrote: > >> You're making a very typical engineering decision-making mistake IMHO. >> The mistake? Turning every small issue into a big issue and then >> reaching the (flawed) conclusion that you can't solve the big issue >> for various reasons (possibly including insufficient resources). >> >> It's not an all-or-nothing problem. > > Indeed; and apparently the ship has sailed, some method scripts > are already ksh or ksh93: > > 1 ELF binary > 1 ksh -p > 3 ksh93 > 7 ksh > 108 sh > > There's no reason to make all scripts use the same shell.
Exactly. That's Tony's point. The bulk of the intricate functionality is provided by a .sh file that is included by other method scripts. If it is expanded to use ksh93 syntax, all consumers will need to use ksh93. If it is written in sh, both ksh93 and sh (and presumably bash and zsh) consumers can use it. >> It's a small issue and the >> proposed solution is well worth the time/effort. It hasn't been made clear that the proposed solution is "well worth the time/effort". For starters, I haven't seen a proposed solution, only a suggestion that ksh93 could eliminate a few uses of sed. Secondly, if I'm looking at the right code, we should be talking about refactoring it long before talking about changing the language it is written in. Finally, while moving to ksh93 isn't a big deal, it is something else that consumers would need to do -- something that could be the one thing that prevents the consumer (who isn't Tony) from participating in this firewall mechanism. Since the goal of this project is to deliver a useful firewall mechanism, not promote ksh93 usage, it is more important to provide something that can be more widely adopted. Dave
