Next in Review Queue: The New std.path

[Lars T. Kyllingstad]

On Fri, 15 Jul 2011 15:34:37 -0400, Nick Sabalausky wrote:

> "Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message
> news:ivpnr5$gf5$7 at digitalmars.com...
>> On Fri, 15 Jul 2011 04:33:34 -0400, Nick Sabalausky wrote:
>>
>>> - Maybe there should be a function canonical() that resolves symbolic
>>> links, runs absolutePath() and normalize(), and on Windows converts to
>>> lowercase. Doesn't need to be in there right now though, could wait
>>> for a later release.
>>
>> I'd be more in favour of adding a resolveSymLinks function to std.file.
>> In any case, I'd prefer it not be part of this proposal, and rather be
>> added later.
>>
>>
> Oh, yea, I didn't mean to imply that there shouldn't be a
> resolveSymLinks function. But I strongly believe that a function which
> combines all of that (and maybe the 8.3 -> full-name expansion on
> Windows, and maybe expansions of things like %APPDATA%) and guarantees a
> single unique canonical name for each actual (existing or non-existing)
> file would be a very, very, very good thing to have. Essenital, in fact,
> for comparing filepaths.
> 
> In any case, I agree that this can all wait until a later time and
> doesn't need to be in this proposal.
> 
>> I haven't done anything to glob (i.e. fnmatch in the current std.path)
>> except change its name and improve its documentation.  For all intents
>> and purposes, it is not part of my submission.  If I find the time,
>> however, I'll look into improving it.
>>
>>
> I see. In that case, maybe its name should remain fnmatch for now (or
> fnglob if you really want "glob" in there). That would prevent confuson
> both now and whenever it gets improved.

Fair enough.  I'll think of a better name and fix it.

-Lars