Would that not introduce an incompatibility between older and newer
versions of /bin/sh?
Obviously, but that is the price of progress.
That's where we disagree. It is certainly progress for languages other
than /bin/sh. But creating the conditions under which a given script will
break is not everyone's definition of progress.
POSIX surely has a way of figuring out at shell level to which version
of the standard a system complies to, so careful application writers who
care about this can test this and act appropriately.
Application writers cannot be so careful as to test operating systems they
don't have access to. Is this not what standards are for? How does
compromising the backwards compatibility of future /bin/sh scripts square
with the expected deliverable of a standards organization?
Whether { bash ksh zsh dash tcsh csh } implement the
feature is relatively tangental.
No, because on many systems, bash or ksh are the de facto /bin/sh
implementations.
Don't forget dash, but then these shells are supposed to be /bin/sh
compatible by introspection. Failed implementations, intentional or
otherwise, should not be accommodated by changing the standard of the only
shell that developers can turn to for compatibility. When they need
features they use other shells or scripting languages. When they need to
maximize compatibility they use /bin/sh.
Thus, scripts written for these systems automatically benefit
from the proposed extension (in that they suddenly become POSIX
compliant), whereas adding new syntax to printf(1) requires all
such scripts to be rewritten.
As pointed out earlier, printf is relatively little used in /bin/sh
scripts, but I agree that new printf syntax is not desirable either.
Roger Marquis
|