Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15799
| From | Robert Elz <kre@munnari.OZ.AU> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Filename Expansion bug |
| Date | 2020-01-11 08:39 +0700 |
| Message-ID | <mailman.2381.1578706864.1979.bug-bash@gnu.org> (permalink) |
| References | <CAJV=ESHn1G2+9FSdtpTPT+CtqahNMiWJtRTE71PagS=H+2VA8A@mail.gmail.com> <CAJV=ESGhY7Wu==vMeUS+icoLBYkONBxuUpTdoUsm3fv=EZFiEQ@mail.gmail.com> <66b2510f-a2cf-b4d3-4574-9193a9bc89c4@case.edu> <16319.1578706785@jinx.noi.kre.to> |
Date: Thu, 9 Jan 2020 12:09:22 +0100
From: Mickael KENIKSSI <k.mickael@gmail.com>
Message-ID: <CAJV=ESHn1G2+9FSdtpTPT+CtqahNMiWJtRTE71PagS=H+2VA8A@mail.gmail.com>
| zsh (and ksh) provide the expected result:
As far as I can tell, all shells except bash preserve the
null components, regardless of whether or not pattern chars
appear in filenames to the right or left of the last/first '/'.
I don't think it is a good idea to rely on any specific
behaviour here though - about the only string it makes
sense to compare the results of a pathname expansion with is
the initial pattern (considered as a string) and even there
extreme care is required (particularly if you don't control
the pattern).
That said, I also see no particularly good reason why bash should
be the outlier here.
kre
Back to gnu.bash.bug | Previous | Next | Find similar
Re: Filename Expansion bug Robert Elz <kre@munnari.OZ.AU> - 2020-01-11 08:39 +0700
csiph-web