Hello,
Bastien <b...@altern.org> writes:
>> Ugh. Bastien, could you (or someone else of Org developers) please
>> look into this? Why does the URI above causes the recent version of
>> Org to pass an invalid file name such as
>>
>> ///opt/tomcat/4/apache-tomcat-4.1.40/... to expand-file-name
>
> I will look into this, but I can't promise anything before next week.
>
> Thanks for the heads up,
A quick analysis.
file:path
is a valid file link type in Org. Therefore,
file:///opt/tomcat/4/apache-tomcat-4.1.40/webapps/../user_projects/GHIJSP2/deploy/WEB-INF/sharedfiles/resources/FR/domVal.xml
is parsed as a file link with path:
///opt/tomcat/4/apache-tomcat-4.1.40/webapps/../user_projects/GHIJSP2/deploy/WEB-INF/sharedfiles/resources/FR/domVal.xml
This path passes `file-name-absolute-p' predicate, so "ox-html.el"
concatenates "file://" to
(expand-file-name path)
Since path is absolute, per `file-name-absolute-p', `expand-file-name'
is probably needed for its "and canonicalize it" part.
Note that other export back-ends, like, "ox-md.el", also use this
construct.
FWIW, I don't see any wrong behaviour here (except that "file://" should
probably not be prepended to path in this case).
Regards,
--
Nicolas Goaziou
