I noticed this when trying to exercise configure.lineno on an older version of ash that lacks $LINENO support. However, I don't know if it is worth trying to fix. The problem is that the sed script that converts $LINENO for configure.lineno doesn't know the difference between those tied to configure and those tied to config.status. As a result, config.status has no instances of $LINENO left (they were all converted during configure). So, even though config.status has code in place to check for a broken lineno, the check passes rather than fails, because it doesn't contain instances of $LINENO any more; also, error messages printed on behalf of config.status are reported from the line number in configure where the message was generated in the here-doc, rather than the resulting line number in config.status. And even though I was expecting the creation of config.status.lineno, it was never created.
For the unquoted here-docs used to generate config.status, I suppose we could use m4_pushdef([LINENO], [LINE${empty}NO]) for the duration of the here-doc, to force the resulting config.status to have a literal $LINENO that bypassed the configure.lineno sed script, and make the config.status.lineno generation trigger. But how to address the use of $LINENO inside quoted here-docs? Should we try to enhance the sed script to recognize <<\_ACEOF/_ACEOF line ranges, and not do $LINENO substitution within those ranges? Or do we go the opposite route? We could just simplify config.status and other subsidiary scripts to not even perform the working LINENO check, and just document that if your shell can't handle $LINENO, then error messages from config.status will be tied to the parent script's lines. It would make the startup time of config.status slightly faster to get rid of the $LINENO checks. -- Eric Blake