Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15314
| From | Stephane Chazelas <stephane.chazelas@gmail.com> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Filename expansion bug |
| Date | 2019-08-08 16:07 +0100 |
| Message-ID | <mailman.1068.1565276870.1985.bug-bash@gnu.org> (permalink) |
| References | <CABN8V7MFbLErHGDJTq0fsBJwS8nofcT8+jcd1LQf1QBq_GTPHQ@mail.gmail.com> <20190808143848.GD1218@eeg.ccf.org> <20190808150739.tax42js5akbai6z6@chaz.gmail.com> |
2019-08-08 10:38:48 -0400, Greg Wooledge: [...] > > shopt -s failglob > > command="echo xyz\(\)" > > $command > > ``` > > > > And it was working fine. But somewhere between bash version 4 and 5 I > > realized it generates an error: > > no match: xyz\(\) [...] > And my personal response for this variant of the issue: stop putting > shell commands in string variables and then trying to run them with > unquoted parameter expansion. See: [...] While I'd agree in this case, note that the austin-group thread was mentionning a very similar case: https://www.mail-archive.com/austin-group-l@opengroup.org/msg04213.html That was in autoconf's configure script (including the one shipped with bash) that is /broken/ by that change in 5.0: as_echo='printf %s\n' $as_echo x now runs: printf '%sn' x if there's a file called %sn in the current directory and printf '%s\n' x otherwise (and would cause an error with failglob and run printf x with nullglob). In that case, it's not because the autoconf authors don't know any better but because at that point in the script where $ac_echo is defined, they're trying to support ancient shells that don't have function support. -- Stephane
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: Filename expansion bug Stephane Chazelas <stephane.chazelas@gmail.com> - 2019-08-08 16:07 +0100
csiph-web