On Tue, Jun 14, 2011 at 4:09 PM, Rainer Schuetze <r.sagitario at gmx.de> wrote:

> On 08.06.2011 21:29, Lars Tandle Kyllingstad wrote:
>
>> As you may already know, I've had a new version of std.path in the works for a while.  It is ready now, and I am waiting for my turn in the review queue in the main NG.  In the meantime, I just thought I'd run it by this mailing list to iron out the worst wrinkles.
>>
>> So, if you feel like it, please comment.
>>
>> Code: https://github.com/kyllingstad/phobos/blob/std-path/std/path.d
>>
>> Docs: http://www.kyllingen.net/code/new-std-path/phobos-prerelease/std_path.html
>>
>>
>> -Lars
>>
>
> Looks good to me. A few notes:
>
> - I agree with Jose that toAbsolute and expandTilde feel a little out-of-place in this module as they are not only string manipulation functions.
>
> I think, the way phobos is organized (distinct std.file and std.path
modules) makes this problem inevitable.
The only solutions are to either keep them in std.path (simply as exceptions
to the no-performing-IO rule) or combine std.path and std.file (which is
probably a worse idea).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110614/b0311aed/attachment.html>

On 14.06.2011 23:09, Rainer Schuetze wrote:
> - expandTilde is currently not implemented on windows, but I think a similar functionality using environment variables similar to HOME could work, too. I have no idea how to implement it for other users than the current, though.

I've had to deal with a similar issue, so I thought I'd chime in.  I think expanding tilde to something (like HOMEPATH, which expands to C:\Users\John or similiar) on Windows makes little sense.  You are almost never supposed to create anything directly in that directory. Instead, you use designated subfolders like AppData\Roaming or Documents.

Technically this would work, but it's just not good practice.  Let's not encourage it.

On Tue, 2011-06-14 at 23:09 +0200, Rainer Schuetze wrote:
> On 08.06.2011 21:29, Lars Tandle Kyllingstad wrote:
> > As you may already know, I've had a new version of std.path in the works for a while.  It is ready now, and I am waiting for my turn in the review queue in the main NG.  In the meantime, I just thought I'd run it by this mailing list to iron out the worst wrinkles.
> >
> > So, if you feel like it, please comment.
> >
> > Code: https://github.com/kyllingstad/phobos/blob/std-path/std/path.d
> >
> > Docs: http://www.kyllingen.net/code/new-std-path/phobos-prerelease/std_path.html
> >
> >
> > -Lars
> 
> Looks good to me. A few notes:
> 
> - I agree with Jose that toAbsolute and expandTilde feel a little out-of-place in this module as they are not only string manipulation functions.

In principle, I agree, but I can't think of a better module in which to put them.


> - expandTilde is currently not implemented on windows, but I think a similar functionality using environment variables similar to HOME could work, too. I have no idea how to implement it for other users than the current, though.

The problem is that tilde expansion is a non-existent concept on Windows.  And as torhu points out, it is far from obvious which directory should be used.  Case in point:

http://technet.microsoft.com/en-us/library/cc749104(WS.10).aspx

*Shudder*...  I think adding an expandEnvironmentVars() function to std.process would be a better idea.


> - \\network drives are currently only respected under windows (at least that's what the documentation says). At work I'm using the same syntax on OSX to mount network drives (with forward slashes), so I guess it is also valid on Posix systems.

I have noted that "//" is treated specially in the POSIX specification, but I have never actually seen it in use.  This, naturally, led me to believe that nobody uses it. ;)  Thanks for proving me wrong!

Fortunately, I believe my current implementation handles it quite nicely.  I may have to make a small change to toCanonical() so it doesn't collapse two leading slashes, but that's about it, I think.


> - isRelative and isAbsolute both return false on the empty string, while dirName("") returns ".". Wouldn't that imply that isRelative("") is true?

Maybe. :)  What do others think?


> - when transferring data containing file names between different operating systems, it would be convenient to have the path operation of the other system available, too. While you can deal with posix file names on windows without big problems, the reverse is usually not the case (you have to convert backslashes manually, don't know how to strip drive names, etc). Would it be a good idea to have both versions accessible through namespaces, e.g. Posix.isRooted() and Win.isRooted(), and let the global functions dispatch to the implementation that fits the current OS?

Alas, I suggested this a while ago, but it was shot down.  I even wrote a pretty elegant proof-of-concept implementation of it, if I may say so myself (note in particular lines 167-168):

https://github.com/kyllingstad/ltk/blob/64b1c895fdb8b84181398c8d367ad1534e7f05c1/ltk/path.d

The ensuing discussion (this list, April 2010) can be found here:

http://lists.puremagic.com/pipermail/phobos/2010-April/thread.html#306

I still think it is a good idea, though.

-Lars

On Sun, 2011-06-12 at 15:35 -0300, Jose Armando Garcia wrote:
> On Sun, Jun 12, 2011 at 3:26 PM, Jose Armando Garcia <jsancio at gmail.com> wrote:
> > 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.
> 
> Err. I am okay with resolving "..".

I have thought some more about this, and I think I will simply remove
toCanonical() and replace it with normalize().  After all,

    auto canonicalPath = normalize(toAbsolute(path));

What do you think?

-Lars

On Wed, Jun 15, 2011 at 5:22 AM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> On Sun, 2011-06-12 at 15:35 -0300, Jose Armando Garcia wrote:
>> On Sun, Jun 12, 2011 at 3:26 PM, Jose Armando Garcia <jsancio at gmail.com> wrote:
>> > 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.
>>
>> Err. I am okay with resolving "..".
>
> I have thought some more about this, and I think I will simply remove
> toCanonical() and replace it with normalize(). ?After all,
>
> ? ?auto canonicalPath = normalize(toAbsolute(path));
>
> What do you think?
>
> -Lars
>

The idea looks good to me but the naming seems off to me. I don't like toAbsolute. To me to...() methods imply conversion of type. Think 'toString', which takes some object and makes it a string. Or the template function 'to'... Maybe just 'absolute' is fine.

On Wed, Jun 15, 2011 at 11:20 PM, Jose Armando Garcia <jsancio at gmail.com>wrote:

> On Wed, Jun 15, 2011 at 5:22 AM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> > On Sun, 2011-06-12 at 15:35 -0300, Jose Armando Garcia wrote:
> >> On Sun, Jun 12, 2011 at 3:26 PM, Jose Armando Garcia <jsancio at gmail.com>
> wrote:
> >> > 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.
> >>
> >> Err. I am okay with resolving "..".
> >
> > I have thought some more about this, and I think I will simply remove
> > toCanonical() and replace it with normalize().  After all,
> >
> >    auto canonicalPath = normalize(toAbsolute(path));
> >
> > What do you think?
> >
> > -Lars
> >
>
> The idea looks good to me but the naming seems off to me. I don't like
> toAbsolute. To me to...() methods imply conversion of type. Think
> 'toString', which takes some object and makes it a string. Or the
> template function 'to'... Maybe just 'absolute' is fine.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>


I agree, 'toAbsolute' should be 'absolutePath'
absolutePath(mypath) -> the absolute path from mypath
extension(mypath) -> the extension from mypath
driveName(mypath) -> the drive name from mypath
etc

Also, why is there an extra 'path' link in the Jump To section of the docs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110616/1fa6cb69/attachment.html>

On Thu, 2011-06-16 at 00:55 -0500, Jimmy Cao wrote:
> 
> I agree, 'toAbsolute' should be 'absolutePath'
> absolutePath(mypath) -> the absolute path from mypath
> extension(mypath) -> the extension from mypath
> driveName(mypath) -> the drive name from mypath
> etc

Good idea.  absolutePath() it is.


> Also, why is there an extra 'path' link in the Jump To section of the docs?

I'm pretty sure it's a DDOC bug.

-Lars