man-pages book: Using stdin/stdout more?

man-pages book: Using stdin/stdout more?

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 286 bytes --]

Hi Deri!

I uploaded the script to the repo. :)

Would it be possible to use a pipe instead of the T file?
Would it be possible to generate the PDF on stdout?

That would help hooking the script into the build system.

Cheers,

Alex
-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: man-pages book: Using stdin/stdout more?

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 625 bytes --]

On 12/24/22 02:34, 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?

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.

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: man-pages book: Using stdin/stdout more?

[Deri]

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.
> 
> --

Re: man-pages book: Using stdin/stdout more?

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2738 bytes --]

Hi Deri,

On 12/24/22 23:46, Deri wrote:
> 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!

Oh, there's no pressure at all.  If you need much more time to have something 
more modular, take your time :)

My understanding of perl is close to zero, so I can't help implementing it.

Writing to stdout and reading from stdin as much as possible, or at least asking 
for the file names as much as possible would allow me to construct some Makefile 
code where I have full control of the files being produced (through redirection, 
or at least specification of the filenames), and where they are produced (the 
current makefile has a strong differentiation between $srcdir and $builddir).

If you can split the script into 2 or three smaller independent steps, I think 
I'll be in a better position to understand them and put them in the Makefile.

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]