path normalisation in "base"

Daniel J. Luke dluke at geeklair.net
Tue Oct 11 07:09:37 PDT 2016


On Oct 11, 2016, at 10:04 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Tuesday October 11 2016 09:21:09 Daniel J. Luke wrote:
> 
>> one way to handle it could be:
>> +        # don't normalize absolute paths
> 
> See my previous message about why normalisation might be used here; completing a relative path is clearly another reason.
> 
> I wonder a bit why `port provides` supports relative paths; is it used in scripts (or even Portfiles)?

I think it's just for user convenience.

> I could imagine this:
> 
> {{{
> proc macports::normalize { filename } {
>    set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]
>    return [string map {${nprefix} ${macports::prefix}} [file normalize $filename]]
> }
> }}}
> 
> and then action_provides can use macports::normalize instead of [file normalize].
> 
> I'll presume that [string map] will check if ${nprefix} and ${macports::prefix} are equal before doing a replacement mapping.

If you have a solution that doesn't cause regression, I don't see why it wouldn't be accepted into base/

-- 
Daniel J. Luke





More information about the macports-dev mailing list