URL: <https://savannah.gnu.org/support/?110654>
Summary: On AT&T UnixPC (3b1) autoconf script fails to properly replace $LINENO variable with line number Project: Autoconf Submitted by: alainknaff Submitted on: Sun 15 May 2022 01:07:40 PM CEST Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: Hi, Autoconfigure scripts generated by GNU autoconf pass themselves through a pair sed script to substitute $LINENO variable with the actual line number if the shell itself does not support a $LINENO variable. The first sed script adds a line with just the line number after each line containing $LINENO. The second script then substitutes $LINENO with the contents of next line (the line number placed by first script) This second script fails on AT&T UnixPC (3b1) and leaves some of the line numbers in the file on their line on their own. This is due to a different behavior of sed's "t" command. The "t" command branches to the given label if there has been a successful s/// substitution since the last t command. On most other platforms, "t" only considers substitutions within current "line". However AT&T UnixPC's sed also considers substitutions on previous lines. This breaks the second script if there are 2 lines with LINENO variable that have *exactly* one intervening other line between them. Example: abc $LINENO def fgh $LINENO This is transformed by the first sed script into abc $LINENO 1 def fgh $LINENO 3 The second script first processes the first 2 lines into "abc 1" However, the removal of the "1" from its own line (s/-\n.*//) is counted as a successful substitution, and is remembered (by UnixPC's sed) for the *next* line def (other sed implementations would clear this on passing to next line). As the sed script now thinks that def contains a $LINENO variable, it gobbles up the next line "fgh $LINENO" using N command, substitutes $LINENO with following line (i.e. with nothing, as it hasn't read the 3 into pattern space yet => eventually, it moves on to the next line (the unprocessed 3), and leaves the line number as is in the output, on a line by its own, where this number ends up getting executed as a command, which crashes the script. Fix: this can be addressed by putting an empty branch + label at the end of the second sed script (t end \n :end): ... sed ' s/[$]LINENO.*/&-/ t lineno b :lineno N :loop s/[$]LINENO\([^'$as_cr_alnum'_].*\n\)\(.*\)/\2\1\2/ t loop s/-\n.*// t end :end ' >$as_me.lineno && ... in /usr/share/autoconf/m4sugar/m4sh.m4 N.B. For testing, an AT&T UnixPC emulator can be found at https://github.com/philpem/freebee _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/support/?110654> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/