Date: Thu, 27 Jun 2019 12:27:55 +0200
From: Joerg Schilling <joerg.schill...@fokus.fraunhofer.de>
Message-ID: <5d149a2b.tueush4pd3wqoutl%joerg.schill...@fokus.fraunhofer.de>
| Note that POSIX is a portable source standard and other shells that may
| behave like bash5 currently only compile and work on a single platform.
I haven't been paying much attention here recently (other stuff to do)
and have a lot of unread mail on this list.
But I wanted to address this point in particular when I saw it (it also
came up in some other message I saw in passing) - and apologies one and all
if others have also said what I am about to say, and I just haven't read
your messages yet.
I shall eventually (if needed) return to substantial points of the actual
issues being discussed in this thread sometime later.
First, you're absolutely right that the NetBSD sh isn't (currently)
portable to other systems - though the issue is mostly its build environment,
rather than its code (but yes, <sys/cdefs.h> is a nuisance). Fixing
that is somewhere on my list of things to do one day, but it is not
nearly as high a priority as making the shell work correctly (for my,
and the NetBSD developers' and users' definition of correctly) and
then more efficiently. [Aside: people I know have managed to build
it on other systems, it is not an impossible task - though it is certainly
not trivial either.]
But all that is 100% irrelevant to anything here - POSIX is so that
applications can be portable, not necessarily in order to make the
systems that implement it portable, or even available at all. In fact,
when POSIX (and or the SUS before it) were initially written, the shell
which was mostly used as the basis for the XCU section, was not really
available at all - it was all proprietary sources.
Any of today's POSIX conforming systems can (could) be the same.
The is no requirement, anywhere, that any particular piece of any
of those systems be portable to any other system, or be available for
you to test in any way at all.
To be certified, as I undersand it, the whole system needs to be tested
and verified correct (plus all the documentation, blah blah ...) but I
don't believe that you are any part of that process, nor that any of the
sources for the certified system ever need be made available to anyone.
None of that makes such a system less relevant for determining what the
the actual expected operations and expectations of the shell in the
wild actually are - that is, what the standard should say.
Further, shells that are actively being distributed and used with systems
available now (particularly those that are installed as /bin/sh on the
various different systems) are much more relevant to use in deciding what
is (and should be) the standard than other random code that is used almost
nowhere - whatever its ancient lineage. And whether you can get at them
to test their operations is 100% irrelevant.
Lastly, if you really want to test the NetBSD shell, that is easy to do - all
you need to do is install NetBSD somewhere - which is not a difficult process,
as while it doesn't always handle all the newest hardware all that well, it
is highly portable, and runs on just about every emulation environment you
can imagine (XEN, Virtualbox, VMware, Qemu, ...) as well as on a large
variety of real (bare metal) hardware of many different architectures.
kre
