Some of you might have seen PR bin/52289 (should be pkg/52289) where
because of changes to /bin/sh a configure script that used to work
now fails.
That is because it is using a bashism (maybe more than one, I didn't look),
so probably really needs to be run using bash.
However, if the one line that caused the problem happens to be all that
is a problem, there might be another solution (eventually).
That is, the script attempted a bash only (maybe ksh93 or zsh as well,
I'm not sure) expansion
${#var[@]}
which (I think) means extract the number of elements in the array "var".
/bin/sh (our /bin/sh) can't handle that, we don't have arrays, and they
are not on the list to add. Previously (before the code was tightened)
I have no idea what this might have generated when executed, but it would
not have been nice, certainly not what was expected.
However, we could do what I see that FreeBSD has done (and when I saw it,
I wondered why) and defer the error message until the expansion actually
happens, rather than when it is parsed (provided we can find some way to
parse the thing, which would be possible here, and in most cases.)
The code in this case was in code that only executed on darwin, and there
(I am guessing) /bin/sh == bash and this code would have worked, so if we
had not issued the error during parsing (and the script has no other bashisms
that would mess things up) then it is possible we could keep executing this
with /bin/sh.
What do you all think, should we defer the error (and so never issue it if
the value is never referenced) or keep on enforcing posix sh syntax (or as
much of it as we can stomach) ?
kre
ps; if this change is to happen, it will probably not be very soon, other
issues seem more important right now.
