in reply to compilation problems

I decided to try an older perl and installed 5.20.3 but the problem persisted.

Perhaps, but the problem is not with that particular subroutine.

$ cat 1204426.pl sub substitute_ac_subst_variables { my ($text) = @_; $text =~ s/\${([^ \t=:+{}]+)}/substitute_ac_subst_variables_worker ( +$1)/ge; return $text; } $ perl -cw 1204426.pl 1204426.pl syntax OK $ perl -v This is perl 5, version 20, subversion 3 (v5.20.3) built for x86_64-li +nux-thread-multi (with 16 registered patches, see perl -V for more detail) Copyright 1987-2015, Larry Wall Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 source ki +t. Complete documentation for Perl, including FAQ lists, should be found +on this system using "man perl" or "perldoc perl". If you have access to + the Internet, point your browser at http://www.perl.org/, the Perl Home Pa +ge. $

Replies are listed 'Best First'.
Re^2: compilation problems
by 1nickt (Canon) on Nov 28, 2017 at 14:00 UTC

    FWIW I get syntax errors with that code on Perl versions back to v5.22.4.

    The change: https://perldoc.perl.org/perl5220delta.html#A-literal-%22%7b%22-should-now-be-escaped-in-a-pattern.

    "f you want a literal left curly bracket (also called a left brace) in a regular expression pattern, you should now escape it by either preceding it with a backslash ("\{" ) or enclosing it within square brackets "[{]" , or by using \Q ; otherwise a deprecation warning will be raised. This was first announced as forthcoming in the v5.16 release; it will allow future extensions to the language to happen."

    Update: marto beat me to it ...


    The way forward always starts with a minimal test.