tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Weirdness in /bin/sh of 8.0



Yeah, I'm dragging a private conversation back onto the list.  Is it
poor etiquette?  Sure.  But this is important.  If left unchecked, we
are talking about a fundamental shift in the development doctrine of
this operating system. 

On Wed, Aug 15, 2018 at 08:25:37AM +0700, Robert Elz wrote:
> Yes, there is.   Mostly bug fixes.

See, this is the start of your madness.  What bugs?  You are pretending
like there's an enormous mountain of debris from /bin/sh constantly
exploding all over the world.  It is not.  Every minute of every day
cron jobs are executing shell scripts flawlessly, rc scripts are
returning 0's without issue, and user scripts are happily doing what
they're supposed to be doing.

I want a list of PRs.  Legitimate "the shell is broken" PRs.  And you
hanging your changes on them.

After a cursory glance, I can only find a couple dozen, which are mostly
many years old, related to poorly written scripts or more recent
interactive additions, or deviations from mistaken user expectations of
behavior.

> There is a standard which says how the shell should behave.

Yeah.  I'm as familiar with the Open Group shell command language
standard as (I hope) you are.  And we both likely know two things:  1)
that if someone ponied up the dollars the existing ash-based /bin/sh
would pass conformance testing without issue, and 2) that there's an
enormous amount of ambiguity everywhere.  Such that what you're actually
doing is advocating your interpretation of the standard and pretending
that non-conformance with that interpretation is a "bug."

> And beyond that, being different from other shells, even when
> allowed, just causes problems for everyone, and certainly
> when there is no good reason for the difference.

Do not feign carrying some sort of standards banner.  What causes
problems for everyone is changing the foundations upon which they have
built their systems.

Incidentally, I would love to hear you make the same argument around
our make(1).

>   | And your "enhancements" have
>   | absolutely no place in the system scripting shell.
> 
> The shell is also the default login shell for users.   And
> while some of the enhancements are directed toward that

Ohh.  Well.  Obviously the solution to the "default login shell is
insufficiently feature rich for users" problem is to change the
fundamental design intention of the most important interpreter in the
entire system.  The notion of changing that default useradd(1) shell to
/bin/ksh or providing some level of documentation regarding the joy of
chsh(1) is clearly beyond contemplation.

Here in the modern era, the /bin/sh is for scripts.  It is not for
users.  If you as a user want interaction, there's a plethora of options
which have come along in the past fifty years, (e.g. ksh).  No one in
their right mind uses /bin/sh as their command line.  Just as no one in
their right mind uses a 300 baud line printer as a terminal.

> (some of which were required by the standard - of
> which there are more to come) but others are very
> much intended to make the shell work better for scripts.

"There are more to come."  A nice little threat.  Changes which are
"required by the standard."  That's funny.  Because the last change I
recall having anything to do with Shell Command Language revolved around
the formatting of the bloody help text.  In which case, I strongly
support the patching.

If, however, you want to do something more under the cover of some kind
of standards compliance, I request that you actually bother to cite it
and not simply wiggle your fingers and make "wooo-oooo-standards-oooo"
noises.

>   |  Find another hobby.
> 
> Not going to happen.   You're welcome to find a different
> OS, or just replace the NetBSD /bin/sh with a different
> one - including writing one for yourself, if you want.

Well, that's not going to happen either.  No, sir, I have no desire to
find another OS -- it is not your place to cast me out.  No, sir, I have
no desire to replace my /bin/sh with a prior version -- I want you to
stop fecklessly mucking about with the one that has been shipping for
years.  No, sir, I have no desire to write one for myself -- there is a
perfectly good Almquist shell.

It frankly boggles my mind that you can be capable of such reckless
behavior.  We're talking about one of the most core components of an
operating system.  An operating system upon which millions (more?) of
people rely for their lifestyle, livelihood, and in some cases life and
safety.  The investments made in the products and services built upon
this operating system are incalculable.  Every time you touch it, you
create ripples of uncertainty and generate work for all those people.

Do you understand that?  Do you understand the responsibility which is
assumed by working on the components you have chosen?

If you do not and you continue to behave as you are, you will be
actively contributing to the end of this project.  People invest their
time and money into tools which save them work and not into those which
generate more of it.

Do you know what a responsible systems developers do in this case?  They
work in parallel.  They offer rationale for their changes.  They solicit
feedback and consider it.  They build their new artifact in a place
where it can be readily slipped into place by those who /choose/ to make
the effort to test.  The fruit of all this is to build confidence to a
point at which a transition may be considered for its cost/benefit and
perhaps implemented.

> Or, as was said on the list, you can just checkout the
> /bin/sh sources from NetBSD 0.8 if you like, and use
> that.

Cute.  Or I could build dash.  Or engage a thousand different
workarounds for your madness.  But all of them point back at the single,
simple principle of my confronting you:

   It is not your place to create work for me or anyone else.  If you
   want a change, you make it so that only affects you and then invite
   others to follow.

You could build elzsh.  And those who want to test it can just symlink
/bin/sh to it.  Maybe in the next release, one can drop in the
replacement.  But no.  You want to be a Poettering about this.

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


Home | Main Index | Thread Index | Old Index