On Thu, Jul 13, 2017 at 05:15:30PM +0200, Edgar Fuß wrote: > There are people who write the scripts that are executed. > I'm one of these people. Well-designed improvements in the langue I use make > my life easier.
Use a language more suitable to your task. Do not make the rest of us pay the price for your convenience. You want ksh features? Use ksh. You want python features? Use python. > I also deduce that you, without knowing any of those, regard my system > management scripts of no value (they probably don't work with 4.4-Lite's > /bin/sh). Their utility to you on the target system is obvious. Their utility to you or anyone else on a different system is zero. The cost of making them useful elsewhere and to others would be porting -- either your program or the environment. Your decision to work in such a way is your own. I'm telling you not to affect my environment in order to support it. > I> [dash] does not strip functionality, it never implemented it. > You may want to learn about the history of ash and dash. That's quite the editorial liberty you've taken there. I'm speaking of our Almquist derivative, not dash. > Yes. But ``don't change anything'' doesn't seem a good doctrine for all > programming languages. "Don't change anything" is not equivalent to "maintain consistency". And you're right. There were many languages that routinely made sweeping changes. They're dead now. You know which ones survive? The ones that plant flags of feature sets, e.g. C, Fortran, COBOL, Ada, etc., so that you can code to a target and know just what to expect. > I> If you want ksh features, use ksh. > [If you want to stick to 4.4-Lite, you know where to find it.] I don't think you understand how successful software works. The lesson in this case: You do not force action on the part of your users; they will not take it. When you break things for them, they will "fix" the problem exactly once -- by abandoning it. > I> The /bin/sh is finished software. > Amen. Did you ever run into sh bugs? Can't say that I have, because the core functionality has been well tried and tested for a few decades now. And, as I've pointed out up-thread, bug fixes are responsible maintenance. (There's a third spot in the middle, which is a "bug" fix that changes expected behavior and therefore breaks well established work-arounds. But let's not wade into that little tarpit.) The lack of a feature is not a bug. It sounds like you've encountered bugs. Where, pray tell? In NetBSD's /bin/sh or another shell? Where do they tend to be found, in the core code or the "advanced" features? A bit of a tangential question: since you aware that bugs exist, what kind of software do you prefer to run when exercising superuser rights? > It forks too much, for one thing. Hmmm, yes, it definitely sounds like you're trying to use the shell for functionality which is more correctly performed by an actual program. May I suggest not doing that? -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__
