Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Mickael KENIKSSI <k.mickael@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Filename Expansion bug
Date: Wed, 8 Jan 2020 08:34:02 +0100
Lines: 28
Approved: bug-bash@gnu.org
Message-ID: <mailman.2243.1578475726.1979.bug-bash@gnu.org>
References: <CAJV=ESGhY7Wu==vMeUS+icoLBYkONBxuUpTdoUsm3fv=EZFiEQ@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Precedence: list
Xref: csiph.com gnu.bash.bug:15791

Hello,

I found a bug regarding how pathnames are processed during filename
expansion. The result for non-normalized path-patterns may get mangled in a
such a way that it becomes inconsistent and unpredictable, making it
useless for string comparison or any kind of string manipulation where
having it in the exact same form as the pattern is required.

How to reproduce :

$ mkdir -p a/b/c d/e/f g/h/e; printf '%s\n' .////*//*///////*
> .////a/b/c
> .////d/e/f
> .////g/h/e
>

This is correct from a filesystem perspective but not from a string
perspective, where you'd need each of the computed path as-is:

.////a//b///////c
> .////d//e///////f
> .////g//h///////i
>

This occurs on all versions >=3D Bash 3.2.

Best regards,
Micka=C3=ABl