Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15794
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Filename Expansion bug |
| Date | 2020-01-08 10:09 -0500 |
| Message-ID | <mailman.2253.1578496195.1979.bug-bash@gnu.org> (permalink) |
| References | <CAJV=ESGhY7Wu==vMeUS+icoLBYkONBxuUpTdoUsm3fv=EZFiEQ@mail.gmail.com> <66b2510f-a2cf-b4d3-4574-9193a9bc89c4@case.edu> |
On 1/8/20 2:34 AM, Mickael KENIKSSI wrote: > 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 You're not going to get the path with multiple slashes preceding pattern characters, because the pathname has single slashes, those slashes are, as POSIX says, "explicitly matched by using one or more <slash> characters in the pattern," and the matched pathnames that replace the pattern don't have multiple slashes. The reason that the three leading slashes aren't removed is that those directory names don't have any pattern characters and are left unchanged. Since the kernel's filename resolution treats multiple slashes the same as a single slash, the constructed pathname matches what's in the file system. That means, for instance, you have a directory `.////' and a pattern `*'. You opendir `////' and read it for every filename matching `*' (a, d, g), construct the pathnames, and go on with the rest of the pattern. The intermediate runs of multiple slashes get removed as part of the matching algorithm, as described above. They're essentially null pathname components. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: Filename Expansion bug Chet Ramey <chet.ramey@case.edu> - 2020-01-08 10:09 -0500
csiph-web