Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15799 > unrolled thread

Re: Filename Expansion bug

Started byRobert Elz <kre@munnari.OZ.AU>
First post2020-01-11 08:39 +0700
Last post2020-01-11 08:39 +0700
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Filename Expansion bug Robert Elz <kre@munnari.OZ.AU> - 2020-01-11 08:39 +0700

#15799 — Re: Filename Expansion bug

FromRobert Elz <kre@munnari.OZ.AU>
Date2020-01-11 08:39 +0700
SubjectRe: Filename Expansion bug
Message-ID<mailman.2381.1578706864.1979.bug-bash@gnu.org>
    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


[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web