From: Deri <deri@chuzzlewit.myzen.co.uk>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: linux-man <linux-man@vger.kernel.org>
Subject: Re: man-pages book: Using stdin/stdout more?
Date: Sat, 24 Dec 2022 22:46:28 +0000 [thread overview]
Message-ID: <2140212.Mh6RI2rZIc@pip> (raw)
In-Reply-To: <43941d08-2277-28ec-8536-19a2b6e35469@gmail.com>
On Saturday, 24 December 2022 10:37:50 GMT Alejandro Colomar wrote:
> > Hi Deri!
> >
> > I uploaded the script to the repo.
> >
> > Would it be possible to use a pipe instead of the T file?
>
> Or even better, because having the intermediate file is interesting for
> debugging. How about breaking the process into 2 scripts, both of which
> write to stdout?
Hi Alex,
The T file is essential (as well as useful), but you are correct the program
can easily be split into two. The lines between 61 and 66 could easily be
included in a makefile and their output switched to STDOUT.
The reason the T file is required is because of the double groff call in line
64. Groff is a single pass system so we need a way to resolve whether a .MR is
a valid link and should be shown as a hotspot (blue) or points outside the
book, so can't be a hotspot. So the first call to groff includes -z which
means that groff will not "produce" any output on STDOUT but because
PDF.EXPORT is defined a list of defined links is output by .tm statements to
STDERR which is then switched to STDOUT. This list of defined links is then
read by the second groff call followed by the T file again, and this time
groff has the -Z flag so it produces a file in groff_out format. This again
has to be written to an intermediate file (LinuxManBook.Z) since the call to
gropdf joins two files, the cover and the book.
I hope this explains the shenanigans. In makefile terms, LinuxManBook.pdf is
dependent on LMBfront.Z and LinuxManBook.Z. Which in turn are dependent on
LMBfront.t and the T file (please think of a better name - LinuxManBook.T
springs to mind! I can use the dasher program for emails, but coding requires
fingers and keys which is much, much, slower so my code style tends to the
minimal!
Cheers
Deri
>
> Then a wrapper would only have to call the two scripts. Maybe the second
> can even read from stdin.
>
> Cheers,
>
> Alex
>
> > Would it be possible to generate the PDF on stdout?
> >
> > That would help hooking the script into the build system.
>
> --
next prev parent reply other threads:[~2022-12-24 22:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-24 1:34 man-pages book: Using stdin/stdout more? Alejandro Colomar
2022-12-24 10:37 ` Alejandro Colomar
2022-12-24 22:46 ` Deri [this message]
2022-12-24 22:56 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2140212.Mh6RI2rZIc@pip \
--to=deri@chuzzlewit.myzen.co.uk \
--cc=alx.manpages@gmail.com \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox