Proposal for std.path replacement

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Sun Mar 6 07:33:14 PST 2011


On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote:

> On 03/06/2011 12:56 PM, Lars T. Kyllingstad wrote:
>> On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
>>
>>> Looks good overall. I have a few comments and nitpicks though:
>>>
>>>   >    basename("dir/subdir/")             -->   "subdir"
>>>   >    directory("dir/subdir/")      -->   "dir"
>>>
>>> Is this what everybody expects? I'm not sure, but another possibility
>>> would be to treat these as if "dir/subdir/." is passed.
>>
>> I don't know about everybody, but it is what *NIX users expect, at
>> least.  I have written those functions so they adhere to the POSIX
>> requirements for the 'basename' and 'dirname' commands.
>>
>>
>>> What is the
>>> result of directory("/") or directory("d:/")?
>>
>> "/" and "d:/", respectively.  The first is what 'dirname' prints, and
>> the second is the natural extension to Windows paths.  (I believe I
>> have covered most corner cases in the unittests.  I think it would just
>> be confusing to add all of them to the documentation.)
>>
>>
>>>   >    extension("file")               -->   "" extension("file.ext")
>>>   >        -->   "ext"
>>>
>>> What about "file."? I tried it on NTFS, but trailing '.' seems to
>>> always be cut off. Is it possible to create such a file on unix
>>> systems? If yes, you won't be able to recreate it from the result of
>>> basename() and extension().
>>
>> Good point.  I don't know if there is any kind of precedent here.  What
>> do others think?
>>
>>
>>> What about network shares like "\\server\share\dir\file"? Maybe it
>>> should also be shown in the examples? Does the "\\server" part need
>>> special consideration?
>>
>> Hmm.. that's another good point.  I haven't even though of those, but
>> they should probably be covered as well.  I'll look into it.
> 
> What about extending the notion of 'device' (see other post) to cover
> 'http://' and "ftp://"?
> Would it be complicated?

I don't think std.path should handle general URIs.  It should only have 
to deal with the kind of paths you can pass to the functions in std.file 
and std.stdio.

-Lars


More information about the Digitalmars-d mailing list