On 15/01/2019 11:03, Joerg Schilling wrote:
Harald van Dijk <a...@gigawatt.nl> wrote:
On 14/01/2019 13:32, Joerg Schilling wrote:
posh does not work on platforms with a POSIX compliant getopt(), so there are
other reasons not to take posh into account.
This is misleading. There are platforms with a POSIX compliant getopt()
on which it does not work, but there are also platforms with a POSIX
compliant getopt() on which it does work. Almost all shells, if not all,
rely on extensions and/or make some not-100%-portable assumptions. That
is not a good reason to disregard them.
But code that does not work on (some) POSIX compliant platforms is not POSIX
compliant as it is in conflict with the POSIX rules.
Code that does not work on some POSIX compliant platforms does not match
the requirements on Strictly Conforming POSIX Applications. However,
there is no requirement on implementations to implement all utilities as
Strictly Conforming POSIX Applications, nor would it make sense to
require that.
Implementations may choose to implement their utilities in a language
other than C, limiting portability.
Implementations may choose to not support 16-bit int, and write code
that only works if int has at least 32 bits, again limiting portability.
Implementations may choose to not support EBCDIC and write code that
only handles ASCII, yet again limiting portability. You seem to have
done this yourself in at least some cases, if I read your code correctly.
posh does not work because it sets "optind" to 0 even though POSIX requires it
to be initialized with 1.
Implementations are allowed to accept this as an extension, and if they
do, they are allowed to make use of that extension in their utilities.
The question is not whether posh acts as a POSIX-conforming shell on all
POSIX systems, but whether it's possible for an implementation that uses
posh as its sh implementation to meet POSIX's requirements. The way
optind is getting set is not a problem for that.
Cheers,
Harald van Dijk
