Path: csiph.com!tncsrv06.tnetconsulting.net!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: Filename Expansion bug
Date: Wed, 8 Jan 2020 10:09:46 -0500
Lines: 50
Approved: bug-bash@gnu.org
Message-ID: <mailman.2253.1578496195.1979.bug-bash@gnu.org>
References: <CAJV=ESGhY7Wu==vMeUS+icoLBYkONBxuUpTdoUsm3fv=EZFiEQ@mail.gmail.com> <66b2510f-a2cf-b4d3-4574-9193a9bc89c4@case.edu>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: chet.ramey@case.edu
To: Mickael KENIKSSI <k.mickael@gmail.com>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
In-Reply-To: <CAJV=ESGhY7Wu==vMeUS+icoLBYkONBxuUpTdoUsm3fv=EZFiEQ@mail.gmail.com>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:15794

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/