Output filename for man pages using a2x

95 views
Skip to first unread message

Rainer Müller

unread,
May 6, 2009, 9:16:41 PM5/6/09
to asci...@googlegroups.com
Hi,

I am currently writing a man page describing multiple commands. I am
using a2x to convert the *.txt to a man page (or HTML). For some reason,
the output name is generated from the names specified in NAMES.

Using the following NAME section, a2x creates "foo,_bar.1" as output
file instead of the intended "foo.1".

NAME
----
foo, bar - Do some foo


I am running the command as follows:

$ a2x -f manpage foo.txt
...
Note: Writing foo,_bar.1

See the attachment foo.txt for the whole example file with the issue.

I already tried passing --xsltproc-opts='--output foo.1' but it seems to
be ignored by xsltproc. Is there another way to overwrite this
auto-generated filename?

Rainer

foo.txt

Stuart Rackham

unread,
May 8, 2009, 5:06:23 PM5/8/09
to asci...@googlegroups.com
The problem stems from the fact that AsciiDoc puts both the names into a
single DocBook refname element:

<refname>foo, bar</refname>

Instead of:

<refname>foo</refname>
<refname>bar</refname>

The latter is semantically correct and when processed generates two man
page files, you see these messages:

Note: Writing foo.1
Note: Writing bar.1 (soelim stub)

This is correct because you want to be able use both 'man foo' and 'man
bar' commands.

So I think this is a bug in AsciiDoc, it should split the names and emit
multiple refname elements. I've added it to the TODO list.

There's no way to override the auto-generated file name from AsciiDoc.

Cheers, Stuart

>
> Rainer
>
> >
>

Stuart Rackham

unread,
May 8, 2009, 10:37:59 PM5/8/09
to asci...@googlegroups.com
I've posted a fix to the trunk:
http://hg.sharesource.org/asciidoc/rev/fc5a653a30a3

Cheers, Stuart

Rainer Müller

unread,
May 9, 2009, 8:22:10 AM5/9/09
to asci...@googlegroups.com
On 2009-05-09 04:37, Stuart Rackham wrote:
> I've posted a fix to the trunk:
> http://hg.sharesource.org/asciidoc/rev/fc5a653a30a3

This looks good. As some sort of workaround I am now using multiple
files and include large parts of the text from a common file.

Thanks for the fix, will consider again to merge this into a single file
after one of the next releases.

Rainer

Reply all
Reply to author
Forward
0 new messages