[phobos] RFC: std.path

[Jose Armando Garcia]

Em 12/06/2011, às 14:00, Lars Tandle Kyllingstad <lars at kyllingen.net>  
escreveu:

> On Sun, 2011-06-12 at 13:36 -0300, Jose Armando Garcia wrote:
>> On Sun, Jun 12, 2011 at 12:59 PM, Lars Tandle Kyllingstad
>> <lars at kyllingen.net> wrote:
>>> On Sun, 2011-06-12 at 12:41 -0300, Jose Armando Garcia wrote:
>>>> On Sun, Jun 12, 2011 at 12:15 PM, Lars Tandle Kyllingstad
>>>> <lars at kyllingen.net> wrote:
>>>>> On Sun, 2011-06-12 at 11:39 -0300, Jose Armando Garcia wrote:
>>>>>> On Wed, Jun 8, 2011 at 4:29 PM, Lars Tandle Kyllingstad
>>>>> These functions are from the old std.path, and I haven't made any
>>>>> changes to them in my version.
>>>>>
>>>>> - toAbsolute()
>>>>> - toCanonical()
>>>>>
>>>>
>>>> In the comments where you say that it doesn't perform any IO you
>>>> should add these functions.
>>>
>>> Does getcwd() perform any IO on Windows?  AFAIK, on POSIX it just
>>> queries /proc/self/cwd, which is a virtual file.
>>>
>>
>> The way I look at IO is anything that is external to the process.
>> Another way to thinking about it is that
>> toAbsolute()'s and toCanonical()'s result is dependent on state
>> outside of the process. While the rest of the templates/functions
>> aren't.
>
> The way I've interpreted the "no IO" principle of std.path is "no
> disk/network IO", since those would come with an enormous performance
> penalty as compared to in-memory operations.  But maybe you are right.
>
>
>>>> Speaking of which can we add a template
>>>> called normalize (maybe you can come up with a better name) that  
>>>> does
>>>> what canonical does but doesn't make it absolute. E.g.:
>>>>
>>>> version(windows) assert(normilize("dir/file") == "dir\\file");
>>>> version(windows) assert(normilize("dir/./file") == "dir\\file");
>>>> //etc
>>>
>>> That sounds like a good idea.  Then I guess normalize("../foo")  
>>> should
>>> just return "..\\foo", i.e. leave the ".." unresolved?
>>>
>>
>> It is hard to resolve '..' without looking at the file system when
>> considering soft/sym link due to multiple parents. if 'somedir' is a
>> simlink "somedir/../" != ".".
>
> That is a matter of choice, I guess.  In both bash and zsh, if I type
>
>   cd some_dir/some_symlink/..
>
> I end up in some_dir, regardless of where some_symlink is pointing.
> That is how toCanonical() does things as well, and how I think
> normalize() should work if I end up adding that.

But most program dont behave this way. For example ls, less and vim  
don't do that. I am okay with resolving symlinks but just take note.