groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] soelim and file names defined in string registers


From: Joerg van den Hoff
Subject: Re: [Groff] soelim and file names defined in string registers
Date: Fri, 18 Aug 2006 15:57:42 +0200
User-agent: Thunderbird 1.5.0.4 (Macintosh/20060530)

(Ted Harding) wrote:
On 18-Aug-06 Joerg van den Hoff wrote:
hi,
looking at the docs and the archives I did'nt find this:
if there are preprocessor directives in a sourced file and
the file name is specified  in a string register in the
document errors result.

say I have to files `t2' and `t3' which are to be sourced
from within this document `t1':

==============
.ds fname t3
.so t2
.LP
.so \*[fname]
==============

difference is that `t3' is specified in a string register.
running `soelim' on this yields in the example (t2, t3
containing some pic stuff):
===================================
.lf 1 ./t1
.ds fname t3
.lf 1 ./t2
sourced file's name specified as text.
.PS
boxwid = 0.5
box
down
box
.PE


.lf 3 ./t1
.LP
.so \*[fname]
=========================================

i.e. `t2' is already included, but the second `.so' is not yet expanded(or what???). formatting this (or the orignal `t1')
with something like

groff -s -ms -p -X t1

generates the error:

t3:2: macro error: bad arguments to PS (not preprocessed with pic?).

without preprocessor stuff in the sourced files, everything seems
to work (ms macros do no harm, for instance).

could someone, please, explain what exactly the problem is
(or tell me to RTFM on page xxx...)? even better would be a
solution/work around how to specify file names of sourced files
via variables/string registers from within the document
(the -I option is not what I'm looking for)

many thanks

joerg

Surely, Joerg, the problem is that the file t3 is not seen until
the 'troff' component of the chain is started, since it is troff
that executes ".so". Therefore, since the preprocessor'pic' has
been run before 'troff' starts, 'pic' has not processed the
contents of file t3. This would apply to any file with preprocessor
material in it (e.g. 'eqn').

There is only one work-round that I know for the situation where
you want to bring in a file in the middle of a troff document,
where the file contains preprocessor material.

This involves using ".sy" to cause the system to run the preprocessor
on the file, storing its output into a temporary file, and then
using ".so" to read in the contents of the temporary file.

This would be on the lines of

.sy pic t3 > t3.temp
.so t3.temp
.sy rm t2.temp


So, if you already have the name "t3" defined as the string fname,
the equivalent would be

.sy pic \*[fname] > \*[fname].temp
.so \*[fname].temp
.sy rm \*[fname].temp

which should work.

NB You must be running groff in "unsafe" mode for this, since
"safe" mode suppresses most commands (including ".sy") for
something to be done by the system.

Hoping this helps,
Ted.


Ted,

it does, thanks a lot. I see the problem now: `soelim' (which is the first preprocessor called anyway) silently ignores the `.so' request including the string register and that's why the `.so' survives until troff gets into gear after the other preprocessors, right?

thanks, too, for the workaround. I will think about it (also running "unsafe" is not always desirable ...).

just an idea: the problem would go away if the `.so' request could be told (by a second argument to the request) to rerun all necessary preprocessors on the sourced file before inserting it (the preprocessors could be those specified in the groff call or explicitely specified to the `.so' reguest). would this be a good idea (apart from the someone_has_to_implement_it aspect)?


regards,

joerg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]