Re: Future shell work - comments reqyuested

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

On Thu, Jul 13, 2017 at 09:52:14AM -0400, Thor Lancelot Simon wrote:
> I strongly disagree and note the obvious internal inconsistency in your
> argument (such as it is):
> 
> > If you want features for a scripting environment, use a different shell.
> > 
> > The /bin/sh is an environment intended primarily to execute scripts.

In what way is this inconsistent?  The /bin/sh of 4.4-Lite is perfectly
capable of executing every system management script of value.  It is
possible to bifurcate features beyond this set into categories based on
intended use: interactive and scripting.  So I say "features for a
scripting environment," I mean those features which are intended
primarily for scripting; e.g.  aforementioned 'exp' built-in.  Command
line completion and whatnot are "interactive."

The /bin/sh is primarily a script execution environment -- #!/bin/sh.
Humans use interactive shells that have features.

> In the direction you seem to be headed lies the true and vivid idiocy of
> the Debian shell, which is *larger* than our shell (depending on platform

I'm not headed in any direction.  I want no motion.  I want the last
non-bug-related commit to /bin/sh to have been from some time close to
2008.  I want a consistent, highly compatible platform upon which to
build and perform system management functions.  You do not get that by
adding features -- interactive or otherwise.

If I want a rich interactive experience, I use a different shell.  If I
want a rich scripting experience, I use a different shell -- or one of a
variety of languages for the purpose.  In what way is that "stripping"
functionality?  It didn't exist in the first place -- and is
definitionally unnecessary.

As to the matter of dash, it is more precisely to /my/ point that
continued development on foundational system components is madness.  Of
the two parties arguing here, who is advocating adding complexity and
code?  Who is advocating for duplication of effort?

> and compiler flags, etc.) yet strips out functionality every other modern

It does not strip functionality, it never implemented it.  If you want a
modern shell's features, use a modern shell.

> shell offers, such as command line editing -- for purely doctrinaire
> reasons, since after all, these features were in what they started with.

Doctrine is important.  It guides understanding and decision making.

> Removing features as a way to enforce some kind of religious notion of
> programmer discipline (which seems to be what the rest of your message
> suggests) is dumb.  I would like to see our shell remain about the size
> and speed it is (both of which are best-of-class) but gain something close
> to feature parity with ksh.  I think Robert's work is getting us there.

If you want ksh features, use ksh.

The /bin/sh is finished software.  It does everything it's supposed to
do.  It does so very admirably with efficiency in space and time that
you describe.  Continuing to muck about with it places both these things
in jeopardy.  It is why I am a surprised to see you take this position.

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