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.
