Re: Is .rd implemented at all?

[Dorai Sitaram]

 Wow, this (Oliver's suggestion) actually works.  I get a bunch of diagnostics 
like this:

Use of uninitialized value $file in substr at /usr/local/bin/gropdf line 615, 
<__ANONIO__> line 95.        Use of uninitialized value $name in concatenation 
(.) or string at /usr/local/bin/gropdf line 621, <__ANONIO__> line 95.

(I get a 103 of these couplets, for lines 1 through 103.)

But they don't stop the show, .rd is recognized and the appropriate PDF is 
created.


--d
    On Thursday, December 17, 2020, 09:22:10 AM EST, Oliver Corff 
<oliver.corff@email.de> wrote:  
 
 Hi,

perhaps Dorai's shell is the culprit?

Can you run the following, actually just a variation of the first trial:

$ groff - -T pdf << EOF > myfile.pdf
.rd
This is some input, it will show in the pdf file.

EOF

As soon as the system waits for you to enter the lines beginning with
.rd, the prompt changes to ">", and when you confirm EOF with <CR>, the
normal prompt will show again.

Under any circumstance, your file myfile.pdf should then show the text
as typed above.

If this fails, you should check the safe/unsafe settings (see the info
file), but to be honest, this is just an idea, I do not know whether the
safe/unsafe setting will impact reading from stdin.

Oliver.


On 17/12/2020 15:05, Colin Watson wrote:
> On Wed, Dec 16, 2020 at 08:30:33PM -0600, Dave Kemper wrote:
>> On 12/15/20, Dorai Sitaram <ds26gte@yahoo.com> wrote:
>>>  Thanks Dave, for the suggestion. That doesn't seem to be the problem,
>>> however, on my machine (Ubuntu 20.10). No-argument cat works as expected.
>> Then something peculiar to the Ubuntu groff seems to be behind this.
>> Ubuntu is a Debian-derived distro, and the concurrent "local timezone"
>> thread here points out Debian's proclivity to customize groff in
>> incompatible ways.
> The example near the head of the thread works fine for me on both Debian
> and Ubuntu, and this is not something that we customise.
>