[TUHS] The Unix shell: a 50-year view -- second pass feedback wanted

[TUHS] The Unix shell: a 50-year view -- second pass feedback wanted

[Jon Steinhart]

Thanks to everyone who provided me feedback on the first pass, especially
those who suggested "shopt -u flame-off".  Here's the second version.
Once again, would appreciate feedback.

Thanks,
	Jon


I read your "Unix Shell Programming: The Next 50 Years" expecting
some well thought out wisdom.  I was sorely disappointed.

The paper is lacking the generally accepted form of:

 o  What problem are you trying to solve?
 o  What have others done?
 o  What's our approach?
 o  How does it do?

Some particulars:

 o  The paper never defines what is meant by the term "Unix shell."
    I think that you're using it to mean a command interpreter as
    described in the POSIX 1003.2 documents.

 o  There is no 50 year old Unix shell.  I started using Unix in the
    early 1970s, and the command interpreter at the time (Ken Thompson's
    shell) was nothing like later shells such as the Bourne shell (sh
    since research V7 Unix), Korn shell (ksh), C shell (csh), and the
    Bourne again shell (bash).  Unix mainstreamed the notion of a
    command interpreter that was not baked into the system.  The paper
    lacks any discussion of prior art.  In practice, shell implementations
    either predate the POSIX standard or were built afterwards and
    include non-standard extensions.

 o  The paper repeats a claim that the shell has been largely ignored by
    academia and industry.  Yet, it does not include any references that
    support that claim.  In fact, the large body of published work on
    shells and ongoing work on shells such as zsh shows that claim to be
    incorrect.

 o  The paper applies universal complaints such as "unmaintainable" to the
    shell; it doesn't call out any shell-specific problems.  It doesn't
    explain whether these complaints are against the scripts, the
    implementation, or both.  One of the reasons for the longevity of the
    family of shells descended from Bourne's sh is that experienced
    practicioners have been able to write easily maintainable code.
    Scripts written in the 1980s are still around and working fine.

 o  The paper seems to complain that the fact that the shell is documented
    is a problem.  This is astonishing.  Proper documentation has always
    been a key component of being a professional in my decades of experience.
    As a matter of fact, my boss telling me that "nobody will give a crap
    about your work unless you write a good paper" when I was a teenager
    at Bell Labs is what led me to UNIX and nroff.

 o  The paper includes non-sequiturs such as discussions about Docker
    and systemd that have nothing to to with the shell.

 o  The paper has many "nop" statements such as "arguably improved" that
    don't actually say anything.

 o  Examples, such as the one on page 105 don't work as there is no input
    to "cut".

 o  The single result in Figure 1 is insufficient evidence that the
    approach works on a wide variety of problems.

 o  The paper gives the appearance that the authors don't actually understand
    the semantics of the original Bourne shell.  Not just my opinion; I
    received an email from Steve Bourne after he read your paper, and I
    consider him to be a subject matter expert.

 o  Proofreading should have caught things like "improve performance
    performance" on page 107 among others.

I think that the paper is really trying to say:

 o  Programmable command interpreters such as those found in Unix-based
    systems have been around for a long time.  For this paper, we're
    focusing on the GNU bash implementation of the POSIX P1003.2 shell.
    Other command interpreters predate Unix.

 o  This implementation is used more often than many other scripting
    languages because it is available and often installed as the default
    command interpreter on most modern systems (Unix-based or otherwise).
    In particular, it is often the default for Linux systems.

 o  The shell as defined above is being used in ways that are far more
    complex than originally contemplated when Bourne created the original
    syntax and semantics, much less the new features from kash adopted by
    the POSIX standards committee.  The combination of both the POSIX and
    bash extensions to the Bourne shell exposes a new set of limitations
    and issues such as performance.

 o  While much work has been done by the bash implementors, it's primarily
    been in the area of expanding the functionality, usually in a
    backward-compatible manner.   Other shells such as the original ksh and
    later ash and zsh were implemented with an eye towards the performance
    of the internals and user perspectives.

 o  Performance optimization using modern techniques such as JIT compilation
    have been applied to other languages but not to POSIX shell implementations.
    This paper looks at doing that.  It is unsurprising that techniques that
    have worked elsewhere work here too.

It's hard to imagine that the application of this technique is all that's
required for a 50-year life extension.  The title of this paper implies
that it's going to be comprehensive but instead concentrates on a couple
of projects.  It ignores other active work on shells such as "fish".  While
the issues with the paper remain, they would not have been quite so glaring
had it had a more modest title such as "Applying JIT Compilation to the
POSIX Shell".

Re: [TUHS] The Unix shell: a 50-year view -- second pass feedback wanted

[Harald Arnesen]

Jon Steinhart [09/07/2021 20.04]:

>   o  The shell as defined above is being used in ways that are far more
>      complex than originally contemplated when Bourne created the original
>      syntax and semantics, much less the new features from kash adopted by
                                                              ^^^^
>      the POSIX standards committee.  The combination of both the POSIX and
>      bash extensions to the Bourne shell exposes a new set of limitations
>      and issues such as performance.