configure.lineno and config.status

[Eric Blake]

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