Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15791 > unrolled thread
| Started by | Mickael KENIKSSI <k.mickael@gmail.com> |
|---|---|
| First post | 2020-01-08 08:34 +0100 |
| Last post | 2020-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.
Filename Expansion bug Mickael KENIKSSI <k.mickael@gmail.com> - 2020-01-08 08:34 +0100
| From | Mickael KENIKSSI <k.mickael@gmail.com> |
|---|---|
| Date | 2020-01-08 08:34 +0100 |
| Subject | Filename 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
Back to top | Article view | gnu.bash.bug
csiph-web