On Sun, Jun 12, 2011 at 3:26 PM, Jose Armando Garcia <[email protected]> wrote: > Em 12/06/2011, às 14:00, Lars Tandle Kyllingstad <[email protected]> > 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 >>> <[email protected]> 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 >>>>> <[email protected]> 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 "..". _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
