[sr #110654] On AT UnixPC (3b1) autoconf script fails to properly replace $LINENO variable with line number

[Paul Eggert]

Update of sr #110654 (project autoconf):

  Status:None => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thanks for the bug report. Although the 3b1 is a museum piece the Autoconf
manual says other old sed implementations have a similar bug and the fix is
trivial, so I installed the attached.

(file #53209)

___

Additional Item Attachment:

File name: 0001-Work-around-AT-T-3b1-bug.patch Size:0 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110654] On AT UnixPC (3b1) autoconf script fails to properly replace $LINENO variable with line number

[Alain Knaff]

URL:
  

 Summary: On AT 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 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 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 UnixPC emulator can be found at
https://github.com/philpem/freebee






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/