On Tue, Sep 14, 2010 at 20:35, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> On Tue, Sep 14, 2010 at 19:26, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >>> >>>> Change send-email to use Perl's catfile() function instead of >>>> "$dir/$file". If send-email is given a $dir that ends with a / we'll >>>> end up printing a double slashed path like "dir//mtfnpy.patch". >>>> >>>> This doesn't cause any problems since Perl's IO layer will handle it, >>>> but it looks ugly. >>>> >>>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> >>> >>> If you mentioned in the proposed log message that File::Spec::Functions >>> have been with us since Perl 5.6.1, it would have saved me (and others) >>> some time worrying about the portability issues. >> >> I thought you might trust me to write portable code by default :) >> >> Anyway, I forgot to mention it. But one can use the corelist(1) >> program to see when what modules appeared in perl core: >> >> $ corelist File::Spec::Functions >> File::Spec::Functions was first released with perl 5.00504 > > Also using File::Spec / File::Spec::Functions makes code more portable > (with respect to things such as different directory separators, and > volume portion of pathname) than using "$dir/$file". Right, but perl mitigates that to some extent by converting Unix paths on-the-fly to whatever the native platform uses. But of course that falls down in cases like Win32 volume labels. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html