Re: backslashes in output of command substitution trigger GLOB

[Lawrence Velázquez]

> On Oct 10, 2020, at 10:23 PM, idallen@idallen.ca wrote:
> 
> Description:
>    If a word in the output of a command substitution contains a
>    backslash, and the word (without backslash) happens to match a
>    file name, the shell will replace the word with the file name.
>    The backslashes will disappear.  If the word doesn't match a file
>    name, the backslashes are preserved.
> 
>    Backslashes are not GLOB characters.  This matching should not happen.
> 
>    Turn on "shopt -s failglob".  Now, if a word in the output of a
>    command substitution contains a backslash, and the word (without
>    the backslash) doesn't match a filename, bash gives a GLOB "no
>    match" error.  Backslashes are not GLOB characters.  This error
>    should not happen.

Sounds like a problem that will be addressed in 5.1
(https://lists.gnu.org/archive/html/bug-bash/2020-09/msg00019.html):

> From: Chet Ramey <chet.ramey@case.edu>
> Subject: Bash-5.1-beta available
> Date: September 10, 2020 at 10:17:19 AM EDT
> To: bug-bash@gnu.org
> Cc: chet.ramey@case.edu
> Reply-To: chet.ramey@case.edu
> 
> [...]
> 
> This release fixes several outstanding bugs in bash-5.0 and introduces
> several new features.  The most significant change is a return to the
> bash-4.4 behavior of not performing pathname expansion on a word that
> contains backslashes but does not contain any unquoted globbing special
> characters.  This comes after a long POSIX discussion that resulted in a
> change to the standard.
> 
> [...]
> 
> There are a few incompatible changes between bash-5.0 and bash-5.1. The
> change to pathname expansion means that words containing backslashes, but no
> special globbing characters, will not undergo pathname expansion. While
> the bash-5.0 behavior was POSIX-conformant, the change was not well-received.

vq