Re: [PATCH] Define $as_echo and $as_echo_n for backward compatibility.

On 3/13/20 1:57 PM, Zack Weinberg wrote:
> Commit 2b59b6f8a79b8bf77e178ff4e5aa0ede433d39cf removed the internal
> shell variables $as_echo and $as_echo_n.  It turns out that these are
> used by several widely-used third-party m4 files (notably both
> gnulib-common.m4 from gnulib, and ax_pthread.m4 from the Autoconf
> macro archive) as well as any number of existing configure.ac’s.
> 
> Restore these shell variables, unconditionally defining them to use
> printf.  Issue -Wobsolete warnings if they are used, recommending the
> use of AS_ECHO and AS_ECHO_N respectively.  Add a test which checks
> both that they do work and that they trigger warnings.
> 
> OK for trunk?
> 
> zw
> 
> ---
>   NEWS                |  6 +++-
>   lib/m4sugar/m4sh.m4 | 28 ++++++++++++++---
>   tests/m4sh.at       | 74 +++++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 103 insertions(+), 5 deletions(-)


> +
> +# For backward compatibility with old third-party macros, we provide
> +# the shell variables $as_echo and $as_echo_n.  New code should use
> +# AS_ECHO(["message"]) and AS_ECHO_N(["message"]), respectively.
> +dnl The @&t@ prevents a spurious deprecation diagnostic.
> +as_@&t@echo='printf %s\n'

Unpatched bash 5.0 has a bug where calling $as_echo that contains \ can 
result in unintended globbing, where the behavior of the expansion is 
dependent on the contents of the current directory.  Nasty!  But I don't 
see a problem in providing the variable definition for back-compat 
reasons (that is, bash's bug doesn't affect this patch)

https://www.mail-archive.com/[email protected]/msg04237.html

ACK

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org