The ELinks WWW browser comes with documentation in AsciiDoc format, and its makefiles convert that to HTML and whatever. Unfortunately, these conversions must currently run AsciiDoc in unsafe mode. This message describes the reasons and suggests changes to AsciiDoc that might allow ELinks to switch to using it in safe mode.
I found out about this when I upgraded AsciiDoc from 7.0.2 to
7.1.2. The configure script of ELinks had detected that AsciiDoc
7.0.2 did not support the --unsafe option, so the makefiles kept
not using it, even though I had upgraded in the meantime.
AsciiDoc 7.1.2 enabled safe mode by default, resulting in the
following errors:
[ASCIIDOC] doc/elinks.1.html
ERROR: elinks.1.txt: line 38: unsafe: include file:
/home/kalle/build/i686-pc-linux-gnu/elinks/doc/option-command.txt
ERROR: elinks.1.txt: line 81: unsafe: {eval:re.match("elinks", "lynx") ==
None}
ERROR: elinks.1.txt: line 81: unsafe: {eval:re.match("elinks", "lynx") !=
None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "elinkskeys")
== None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "elinkskeys")
!= None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks",
"elinks.conf") == None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks",
"elinks.conf") != None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "links") ==
None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "links") !=
None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "lynx") ==
None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "lynx") !=
None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "w3m") ==
None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "w3m") !=
None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "wget") ==
None}
ERROR: elinks.1.txt: line 171: unsafe: {eval:re.match("elinks", "wget") !=
None}
make: *** [elinks.1.html] Error 1
Most of these errors are caused by this macro in asciidoc.conf:
# Use the man:[] macro to link between elinks manpages
[man-inlinemacro]
{eval:re.match("elinks", "{target}") != None}<a
href="{target}.{0}.html">{target}({0})</a>
{eval:re.match("elinks", "{target}") == None}<b>{target}({0})</b>
I believe this can be rewritten to use conditional attributes and
avoid the unsafe eval, at the cost of requiring AsciiDoc 7.0.4 or
later:
[man-inlinemacro]
[EMAIL PROTECTED]:<a
href="{target}.{0}.html">{target}({0})</a>:<b>{target}({0})</b>}
However, the first error is more insidious. It comes from this line:
include::{builddir}option-command.txt[]
The option-command.txt file is generated by a script that runs
elinks --long-help and converts the result to AsciiDoc. The
output depends on how ELinks was built, so it must be in the
build tree, rather than in the source tree. But elinks.1.txt is
in the source tree, so AsciiDoc in its default safe mode doesn't
let it include the file from the build tree.
I think there are a few ways to resolve this and let ELinks use
AsciiDoc in safe mode:
(a) Change elinks/doc/Makefile to copy elinks.1.txt (and any
other files that hit the same problem) into the build tree
before using them. Unfortunately, this would cause any error
messages output by AsciiDoc to point to files in the build
tree, potentially luring people into editing copies that will
soon be overwritten. Also, elinks/doc/Makefile would then
no longer be able to use VPATH, because it would have to
distinguish between copies of files in different directories.
(b) As in (a) but make symbolic links rather than copies.
At least Emacs can then follow them semiautomatically and
edit the real files instead.
(c) As in (a) but change elinks/doc/Makefile to filter the error
messages and correct any directory references.
(d) Extend AsciiDoc so that a list of safe directories can be
specified on the command line. It would then allow files in
those directories to be included even in safe mode. Change
elinks/doc/Makefile to use this option.
(e) Extend AsciiDoc so that an include path can be specified on
the command line. AsciiDoc would search this path whenever
an include macro specifies a relative file name; in safe
mode, it would not allow subdirectory specifications. Then,
use just include::option-command.txt[] in elinks.1.txt.
While I have minimal experience with Python myself, I expect
change (d) or (e) would not be terribly difficult to implement.
First however, I'd like to know the maintainer's opinion on such
changes. I don't think there'd be much point in bundling a
forked version with ELinks.
pgpDVH4oIpc1V.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
