Re: [PATCH] Define $as_echo and $as_echo_n for backward compatibility.
Eric Blake <[email protected]>
| Newsgroups | gmane.comp.sysutils.autoconf.patches,gmane.comp.shells.bash.bugs |
|---|---|
| Organization | Red Hat, Inc. |
| Message-ID | <[email protected]> |
On 3/13/20 2:22 PM, Zack Weinberg wrote: > On Fri, Mar 13, 2020 at 3:13 PM Eric Blake <[email protected]> wrote: >> >> 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! > > Yikes! And not just unpatched 5.0.0, either... > > $ bash --version > GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu) > $ touch %sn; bash -c 'cmd='\''printf %s\n'\''; $cmd test' > testn$ > > I don't see any practical workaround and I surely hope this gets fixed > *properly* soon in bash (that discussion you linked to doesn't seem > terribly promising, though). You can always make $as_echo expand to the name of a shell function rather than to something that directly contains \, but then we have to worry about making sure the function is defined before anyone that uses $as_echo... I'm wondering if Chet has an update on the matter (adding bug-bash). Repeating some context: https://www.mail-archive.com/[email protected]/msg04237.html was a mail to the POSIX folks last June complaining about how bash 5.0's change to allow \ to trigger globbing has unintended consequences, and breaks many existing configure scripts based on the contents of the current directory. I know the Austin Group finally settled on wording that does indeed explicitly state that unpatched bash 5.0 is buggy: https://www.austingroupbugs.net/view.php?id=1234#c4564 " On page 3749 line 128725 section C.2.13.3, add a new paragraph: Patterns are matched against existing filenames and pathnames only when the pattern contains a '*', '?' or '[' character that will be treated as special. This prevents accidental removal of backslash characters in variable expansions where generating a list of matching files is not intended and a (usually oddly named) file with a matching name happens to exist. For example, a shell script that tries to be portable to systems that predate the introduction of functions and printf might use this on POSIX systems: myecho='printf %s\n' to be used as: $myecho args... If <tt>%s\n</tt> were to be matched against existing files, this would not work if a file called <tt>%sn</tt> happened to exist. " but I don't know where things stand in bash proper to incorporate the result of that discussion (is it something fixed in unreleased batch, and we are just missing a formal patch to the 5.0 series, or is it still unwritten, or...?). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org