Re: Future shell work - comments reqyuested

[Izaac <izaac%setec.org@localhost>]

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?

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__