helpAutoconf - Support: sr #110655, AT&T UnixPC (3b1) shell thrown...

 
 

sr #110655: AT&T UnixPC (3b1) shell thrown off by #( after case.

Submitter:  Alain Knaff <alainknaff>
Submitted:  Sun 15 May 2022 05:50:33 PM UTC
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Wont Do
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Thu 26 May 2022 10:05:35 PM UTC, comment #6: 

comment #4:

> That said, the observation that even current shells will choke on `eval` of shell variables containing long runs of shell code including comments, is valuable.  That's something we should be avoiding in general and not just in this case.
>
> (We should be trying to move away from shell variables containing shell code, period.  That's what shell functions are for.)


Indeed. There is one remaining case of this in _AC_INIT_PREPARE, which sets up a trap to be run on exit (after line 1315 of /usr/share/autoconf/autoconf/general.m4). The trap is a huge string of shell code. IMHO, the bulk of this should be in a function, to be called by a much smaller trap. I'm also getting the impression that this causes problems on low memory machines.

Alain Knaff <alainknaff>
Tue 17 May 2022 08:21:10 PM UTC, comment #5: 

comment #3:

> This is also code that no longer exists in current versions of Autoconf, which instead unconditionally set
>
> as_echo='printf %s\n'
> as_echo_n='printf %s'
>


Not sure whether that is a good thing in the context of this bug, as UnixPC does not contain a printf shell command... (But as it is mostly a wrapper around the printf C function, it could probably be rigged up quite easily)

Alain Knaff <alainknaff>
Tue 17 May 2022 08:12:50 PM UTC, comment #4: 

That said, the observation that even current shells will choke on `eval` of shell variables containing long runs of shell code including comments, is valuable.  That's something we should be avoiding in general and not just in this case.

(We should be trying to move away from shell variables containing shell code, period.  That's what shell functions are for.)

Zack Weinberg <zackw>
Project Administrator
Tue 17 May 2022 08:04:08 PM UTC, comment #3: 

This is also code that no longer exists in current versions of Autoconf, which instead unconditionally set

as_echo='printf %s\n'
as_echo_n='printf %s'

Zack Weinberg <zackw>
Project Administrator
Tue 17 May 2022 12:21:45 PM UTC, comment #2: 

comment #1:

> The #( is not needed by any shell I know of. It's there for two reasons: (1) editors that match parens and get confused by 'case' with unbalanced parens. (2) Autoconf uses that aren't properly quoted and that also get confused with 'case' with unbalanced parens.


ok, I see

>
> (1) and (2) together suggest that we should leave the Autoconf code alone. If you're running on a shell that doesn't do comments correctly, one fix is to port a working shell and use that instead. You might try bootstrapping 'Bash' by editing its configure script with 's/#((*$//' and then running 'configure; make'. Or any other POSIX-confirming shell should do.


On further analysis, I noticed that this code is misinterpreted by the Linux bash as well.

The only reason why this bug isn't much more apparent is that this code is only selected in rare cases where "easier" ways (such as plain echo -n) are not available.

The reason why this is being misinterpreted is because when expanding an (unquoted) variable, the shell (all shells, even bash on Linux) first breaks it into individual arguments, using white space (spaces, newlines, tabs,...) as separators. Eval then pastes those arguments back together, but using plain space, not what was there to begin with. Which means that the multiline variable ends up being interpreted as a single long line. That's also the reason why some lines (such as "arg=$1;") have a semicolon behind them: without it, the command would merge with the following line!

One fix would be to quote the as_echo_n_body variable. However, this would also prevent eval to be broken out as the command, so this has to go outside the quotes, and pasted to the rest via an as_spc environment variable. So the complete code would like the following:

    as_echo_n_body='
      arg=$1;
      case $arg in #(
      "$as_nl")
expr "X$arg" : "X\\(.*\\)$as_nl";
arg=`expr "X$arg" : ".*$as_nl\\(.*\\)"`;;
      esac;
      expr "X$arg" : "X\\(.*\\)" | tr -d "$as_nl"
    '
    export as_echo_n_body
    as_spc=' '
    export as_spc
    as_echo_n='sh -c eval$as_spc"$as_echo_n_body" as_echo'

Alain Knaff <alainknaff>
Mon 16 May 2022 05:28:47 AM UTC, comment #1: 

The #( is not needed by any shell I know of. It's there for two reasons: (1) editors that match parens and get confused by 'case' with unbalanced parens. (2) Autoconf uses that aren't properly quoted and that also get confused with 'case' with unbalanced parens.

(1) and (2) together suggest that we should leave the Autoconf code alone. If you're running on a shell that doesn't do comments correctly, one fix is to port a working shell and use that instead. You might try bootstrapping 'Bash' by editing its configure script with 's/#((*$//' and then running 'configure; make'. Or any other POSIX-confirming shell should do.

Paul Eggert <eggert>
Project Administrator
Sun 15 May 2022 05:50:33 PM UTC, original submission:  

On AT&T UnixPC (3b1), autoconf's configure picks the following implementation for as_echo_n :

    as_echo_n_body='eval
      arg=$1;
      case $arg in #(
      "$as_nl")
expr "X$arg" : "X\\(.*\\)$as_nl";
arg=`expr "X$arg" : ".*$as_nl\\(.*\\)"`;;
      esac;
      expr "X$arg" : "X\\(.*\\)" | tr -d "$as_nl"
    '

However, UnixPC's shell apparently does not understand the #( after "case $arg in", and raises an end of file error.
Simply removing it fixes the problem on AT&T UnixPC.

However, I understand that this might be needed on other architectures.

A more portable solution might be to simply not bother handling newlines which might be embedded with the echoed string, and suppress those as well. Indeed, I have a strong suspicion that echo -n is not ever used by autoconf for a string that contains newlines.

Alain Knaff <alainknaff>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by eggert (Posted a comment)
  • -email is unavailable- added by alainknaff (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-05-16 eggert StatusNone Wont Do
        Open/ClosedOpen Closed

    Back to the top


    Powered by Savane 3.9