Leo wrote: > Albeit File::Spec is using catfile and catdir, I don't like the function > names ("cat file" is on *nix what "type file" is on Win*). Maybe > concat_pathname and concat_filename is better.
Yes, indeed. I'm for having concat_pathname only since this patch or the File::Spec module makes no difference when concatenates paths and files (though I can be mistaken on account of VMS, Dan? (~:). So catdir and catfile give the same result. Morever, catfile is sort of a wrapper around catdir and does nothing smarter than just calling catdir on all platforms. We can bring concat_filename in either (I don't mind) but as an alias of concat_pathname. I don't know how to implement this(I mean aliasing) in terms of parrot, though. Can we do it in some elegant way? However, for consistensy's sakes, I really really want that we have only concat_pathname, because whether we do concatenating of dirs or dirs & file we always do the same -- concatenate a path. > docs/dev is the place for documents about internal functionality and > design decisions. Okay. > WRT the patch - please can people having experience with different > platforms have a look at it, if the functionality would be able to cope > with all platform weirdness. The time being, it can works properly only on windows and unix platforms. Why is it so? I feel I should give some explanations on how it works. There is only one generic function catdir, but not many ones as we have in File::Spec. And there are some filters[1], which we can assign to an array Filters. typedef void (*ParrotFSFilter)(struct Parrot_Interp *, STRING **); ParrotFSFilter Filters[] = { filter_1, filter_2, ... , filter_n }; When we have such a PASM code as set S0, "foo_dir" set S1, "bar_dir" catdir S0, S1 it firstly calls the file_spec_catdir() function which just only glues parts with an OS specific directory separator and directs the control to another function, that is file_spec_filter(). No doubt after the gluing a path can contain some trash like successive slashes, that's why we call file_spec_filter, anyway, which in its turn calls each function registered on the Filters array. Filters could be an OS specific, there is no sense to register filter that does the # xx///xx ->xx/xx changes when you are working on cygwin. Another question is how we can add an OS specific filter -- it's nothing to do: ParrotFSFilter Filters[] = { file_spec_some_filter #ifndef PARROT_OS_NAME_IS_CYGWIN file_spec_successive_slashes_filter, #endif file_spec_filter_which_deletes_redundant_root_direct #ifdef UNIX file_spec_vms_specific_filter, #endif file_spec_yet_another_filter, and so on }; If somebody imagines a plan that could manage without macroing, you know, ideas are always welcome. Now, when you know how it's supposed to work, I can return to the question "why can it works properly only on windows and unix platforms". The answer is: Filters haven't been implemented yet. Because I am still hesitating on accounts of what would be the best solution for find 'n' search actions. And wish I could have heard some comments on that. To clarify what the heck I'm talknig about I put the following fragment that I have cut off of my inital mail ---- Next. In the future I'll need to be able to do some find 'n' replace actions in order to clean the trash off of paths. The perl version uses the regexes like these: $path =~ s|/+|/|g unless($^O eq 'cygwin'); # xx////xx -> xx/xx $path =~ s|(/\.)+/|/|g; # xx/././xx ->xx/xx $path =~ s|^(\./)+||s unless $path eq "./"; # ./xx -> xx $path =~ s|^/(\.\./)+|/|s; # /../../xx ->xx $path =~ s|/\Z(?!\n)|| unless $path eq "/";# xx/ -> xx The bodkin is whether I should take advantage of string_str_index, string_replace and friends or there is a better solution? In any case it never uses long paths, so we won't be violently penalized while using any of find 'n' replace sheme. ---- There is one more thing to have been said, for some cases a result obtained with the parrot file spec will devirege from a result obtained with the perl one. For instance, set S0, "" set S1, "" concat_pathname S0, S1 print S1 prints "", but File::Spec's equivalent my $path = catdir("", ""); print $path; prints "/" on UNIX, windows, and so forth. I don't think it's the Right result, though you can argue with me on that account. I'm gonna document all divegrences. > [ can you switch your mailer to plain text, thanks ] Yep. I regularly do that. But sometimes my MTA outwits me. > [ WRT diff: make a copy of your original tree, do modifications there > and then "cd ..; diff -urN parrot parrot-modified" ] Thanks, indeed. I'll try that as soon as I prepare a new patch.