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


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

Filename Expansion bug

Started byMickael KENIKSSI <k.mickael@gmail.com>
First post2020-01-08 08:34 +0100
Last post2020-01-08 08:34 +0100
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

  Filename Expansion bug Mickael KENIKSSI <k.mickael@gmail.com> - 2020-01-08 08:34 +0100

#15791 — Filename Expansion bug

FromMickael KENIKSSI <k.mickael@gmail.com>
Date2020-01-08 08:34 +0100
SubjectFilename Expansion bug
Message-ID<mailman.2243.1578475726.1979.bug-bash@gnu.org>
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 >= Bash 3.2.

Best regards,
Mickaƫl

[toc] | [standalone]


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


csiph-web