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


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

Re: Filename Expansion bug

Started byChet Ramey <chet.ramey@case.edu>
First post2020-01-08 10:09 -0500
Last post2020-01-08 10:09 -0500
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 Chet Ramey <chet.ramey@case.edu> - 2020-01-08 10:09 -0500

#15794 — Re: Filename Expansion bug

FromChet Ramey <chet.ramey@case.edu>
Date2020-01-08 10:09 -0500
SubjectRe: Filename Expansion bug
Message-ID<mailman.2253.1578496195.1979.bug-bash@gnu.org>
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/

[toc] | [standalone]


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


csiph-web