At 2020-09-29T07:08:20+1000, John Gardner wrote:
> >
> > echo foo | troff >&-
>
> Erh, yeah, that's… probably gonna cause issues...
>
> I get the same error you reported earlier, but why on Earth are you
> closing the file descriptor?
He wasn't. groff was.
I ran groff under gdb, set some bre
At 2020-09-28T13:30:50-0700, hacke...@member.fsf.org wrote:
> I think there may be a race condition caused by the groff pipeline. Just to
> be sure, please try
>
> echo foo | troff >&-
>
> My earlier command was causing troff to dump core when its stdout was
> closed (by grops exiting) befo
>
> echo foo | troff >&-
Erh, yeah, that's… probably gonna cause issues...
I get the same error you reported earlier, but why on Earth are you closing
the file descriptor?
On Tue, 29 Sep 2020 at 06:31, wrote:
> I think there may be a race condition caused by the groff pipeline. Just to
> be
I think there may be a race condition caused by the groff pipeline. Just to
be sure, please try
echo foo | troff >&-
My earlier command was causing troff to dump core when its stdout was
closed (by grops exiting) before it finished writing.
—b9
On Mon, Sep 28, 2020 at 7:04 AM G. Brande
At 2020-09-28T03:44:41+1000, John Gardner wrote:
> The error I get with groff 1.22.4 is different:
>
> $ echo foo | groff -Pbar
> grops: can't open file 'bar'
I can't reproduce this either, with groff 1.22.4 (Debian) or groff git
HEAD.
Regards,
Branden
signature.asc
Description: PGP signature
Does it make a difference if you add a prologue file named `bar`? From
grops(1):
*-P**prologue-file*
Use the file *prologue-file* (in the font path) as the prologue
instead of the default prologue file *prologue*.
The error I get with groff 1.22.4 is different:
$ echo foo | groff -Pbar
grops:
Using groff 1.22.4, groff complains and then dumps core when I do this:
$ echo foo | groff -Pbar
troff: fatal error: error writing output file
groff: troff: Signal 11 (core dumped)
Is it just me or does that happen for everyone?
—b9
On Wed, Jan 23, 2019 at 03:02:26PM +, Ralph Corderoy wrote:
> Hi Colin,
>
> > So this option would also lose support for Debian 8 (currently
> > oldstable).
>
> Also, `<<>>' doesn't support `-' to mean stdin.
> That might affect users of the groff Perl scripts that use `<>'.
Ah, yes - in tha
Hi Colin,
> So this option would also lose support for Debian 8 (currently
> oldstable).
Also, `<<>>' doesn't support `-' to mean stdin.
That might affect users of the groff Perl scripts that use `<>'.
$ pacman -Q perl
perl 5.28.1-1
$
$ perl -e 'while ( <> ) {}' - >) {}' -
On Wed, Jan 23, 2019 at 03:21:53PM +0100, Jakub Wilk wrote:
> * Colin Watson , 2019-01-23, 13:56:
> > Perl >= 5.20 has the safer <<>> operator,
>
> It was actually added only in Perl 5.22.
Sorry, indeed so - I grepped the perl*delta man pages for it but misread
"5220" as "5200". So this option w
> Yes. I would add you as an additional administrator, thus giving you
> write access to the list data.
Sounds good. Happy to look into the bug-groff setup and help out
wherever else I can.
>> Dave, do you want to become admistrator of the `groff' and
>> `bug-groff' mailing lists?
>
> I'm willing to, though if they frequently need prompt administrative
> intervention, I may not be best suited for it (as the tardiness of
> this reply illustrates).
No problem! Most actions (like appr
On 11/8/18, Werner LEMBERG wrote:
>> Is it possible to configure bug-groff to autorespond to any email
>> that doesn't come from the Savannah bug tracker, telling the sender
>> that the tracker is the preferred place to report groff bugs?
>
> Probably yes. Dave, do you want to become admistrator
> Is it possible to configure bug-groff to autorespond to any email
> that doesn't come from the Savannah bug tracker, telling the sender
> that the tracker is the preferred place to report groff bugs?
Probably yes. Dave, do you want to become admistrator of the `groff'
and `bug-groff' mailing
Unsurprisingly, my post to the bug-groff email list
(http://lists.gnu.org/archive/html/bug-groff/2018-10/msg00029.html) about how
no one seems to monitor mail sent there anymore went unanswered.
Groff's documentation has been updated
(http://savannah.gnu.org/bugs/index.php?54910) to direct bug
Haha, don't worry, I respect all open-source licenses. That was intended as
a jovial remark.
Picking a license is, of course, a developer's personal decision.
Personally, I just prefer simplicity and openness, hence my preference for
the ISC license.
Didn't expect that would be taken too seriousl
Hi John,
John Gardner wrote on Fri, Apr 28, 2017 at 11:14:55PM +1000:
> ISC forever!
Well, kind of "no" in the present context.
While i do personally prefer the ISC license for software that
i write myself, i also fully respect James Clark's decision to
publish groff under the GPL, and i do ack
Yikes, that's an ugly dark side.
> Those artificial barriers make it even more important that those
> people who do not mind signing an FSF Copyright assignment do
> actively contribute, and if that should result in an invitation to
> join the groff project, become committers and help to review a
Hi,
Werner LEMBERG wrote on Fri, Apr 28, 2017 at 07:54:55AM +0200:
> g.branden.robinson wrote:
>> It'd be nice if 3 year-old bugs could get some feedback from the
>> maintenance team.
>>
>> What needs to happen to make that possible?
> A new maintainer.
While that would no doubt be excellent,
>> I reported this bug (and in '.IB') in August 2014, #42906
>
> It'd be nice if 3 year-old bugs could get some feedback from the
> maintenance team.
>
> What needs to happen to make that possible?
A new maintainer.
Werner
At 2017-04-27T19:11:29+, Bjarni Ingi Gislason wrote:
> On Wed, Apr 26, 2017 at 11:54:21AM -0400, G. Branden Robinson wrote:
> > At 2017-04-26T15:50:26+0100, Ralph Corderoy wrote:
>
> [...]
>
> > > ??? .IR being is just a shorthand for `\f' and `\^' that can be done
> > > manually when n
On Wed, Apr 26, 2017 at 11:54:21AM -0400, G. Branden Robinson wrote:
> At 2017-04-26T15:50:26+0100, Ralph Corderoy wrote:
[...]
> > ??? .IR being is just a shorthand for `\f' and `\^' that can be done
> > manually when needed, e.g. `.TH'.
>
> FYI, .IR does not give you this "italic correct
Hello,
it should not be a problem for gtbl to restore the tab settings "itself".
If at begin it saves register \n[.tabs] in a string and then set
.ta \*[saved_tabs]
at the end the tabs from before .TS should be set after .TE?
Carsten
|Ralph Corderoy wrote:
||> (For the list: mawk(1) requires a fflush("") in order to "getline <
||> NAME" a file NAME that has been written via "print >> NAME" before,
||> even though fflush("") is not standard and i cannot imagine a
||> situation where an awk(1) script would not like to see a
Ralph Corderoy wrote:
|> (For the list: mawk(1) requires a fflush("") in order to "getline <
|> NAME" a file NAME that has been written via "print >> NAME" before,
|> even though fflush("") is not standard and i cannot imagine a
|> situation where an awk(1) script would not like to see a fflus
Hallo Ingo, list,
Ingo Schwarze wrote:
|Steffen Nurpmeso wrote on Mon, Nov 10, 2014 at 03:21:36PM +0100:
|> Ok, but i really wonder now -- why? If it is normal that .Va and
|> other requests extend until the next macro switches the current
|> mode (the mdoc macros seem to transport significa
Hi Steffen,
> (For the list: mawk(1) requires a fflush("") in order to "getline <
> NAME" a file NAME that has been written via "print >> NAME" before,
> even though fflush("") is not standard and i cannot imagine a
> situation where an awk(1) script would not like to see a fflush("") on
> NAME be
Hi Steffen,
Steffen Nurpmeso wrote on Mon, Nov 10, 2014 at 03:21:36PM +0100:
> Ok, but i really wonder now -- why? If it is normal that .Va and
> other requests extend until the next macro switches the current
> mode (the mdoc macros seem to transport significant amount of
> state from a shallow
Hey, Ingo, Werner, list,
Ingo Schwarze wrote:
|Werner LEMBERG wrote on Sat, Nov 08, 2014 at 02:19:38PM +0100:
|> Steffen Nurpmeso wrote:
|>> [...] i stumbled over a interpretation difference (full source
|>> attached):
|>>
|>> source:
|>> .It Fn at_quick_exit , Fn _atexit
|>> groff a
Hallo Werner,
Werner LEMBERG wrote:
|> [...] i stumbled over a interpretation difference (full source
|> attached):
|>
|> source:
|> .It Fn at_quick_exit , Fn _atexit
|> groff and mandoc agree.
|> .It Fn at_quick_exit , _atexit
|> Only mandoc gets that right.
|>
|> mandoc:
|>
> From: anonymous
> Subject: [bug #43569] Fix for compile warnings with gcc 4.6.3
Thanks!
Werner
On Mon, Nov 10, 2014 at 10:07:01AM +, anonymous wrote:
From: anonymous
Subject: [bug #43569] Fix for compile warnings with gcc 4.6.3
"anonymous" was me. Failed to log in first.
Sorry,
ulrich
Hi Werner and Steffen,
Werner LEMBERG wrote on Sat, Nov 08, 2014 at 02:19:38PM +0100:
> Steffen Nurpmeso wrote:
>> [...] i stumbled over a interpretation difference (full source
>> attached):
>>
>> source:
>> .It Fn at_quick_exit , Fn _atexit
>> groff and mandoc agree.
>> .It Fn at_quick_e
Hello,
i finally come around to implement my proposed mdoc(7) reference
extension and yesterday i stumbled over a interpretation
difference (full source attached):
source:
.It Fn at_quick_exit , Fn _atexit
groff and mandoc agree.
.It Fn at_quick_exit , _atexit
Only mandoc gets that right.
> [...] i stumbled over a interpretation difference (full source
> attached):
>
> source:
> .It Fn at_quick_exit , Fn _atexit
> groff and mandoc agree.
> .It Fn at_quick_exit , _atexit
> Only mandoc gets that right.
>
> mandoc:
> at_quick_exit(), _atexit()
> grof
> Consider the following,
>
> .Bl -column asdfasdf asdfasdf asdfasdf
> .It a ) ] ;b ) ] ;c ) ;
> .El
>
> where is a tab. Why does this produce the following:
>
> a]) ; b]) ; c]);
>^^^ ^^^
>
> In words, each column's last closing-punctuation is buffered by a space,
> Shouldn't this really do
>
> a ] ) ; b ] ) ; c]);
>
> since -separated lines are supposed to behave like columnar real
> lines and only the closing terms are adjusted?
(Answering myself with more possibilities.)
Either that or
a]);b]);c]);
if we're to assume that `
Hello, another groff question.
Consider the following,
.Bl -column asdfasdf asdfasdf asdfasdf
.It a ) ] ;b ) ] ;c ) ;
.El
where is a tab. Why does this produce the following:
a]) ; b]) ; c]);
^^^ ^^^
In words, each column's last closing-punctuation is buffered by a
Werner LEMBERG wrote:
Is there a workaround I can use to force groff/soelim to read foo.ms
in the current directory?
I'm very sorry about this, it's a documentation error on my side --
I've never touched the logic of the related source code.
No problem, I realized after sending my report th
> The manpage for soelim (and groff) says of the -I option: "specify a
> directory to search for files (both those on the command line and
> those named in .so requests). The current directory is always
> searched first."
>
> Reality (with foo.ms in the current directory and in
> /usr/share/groff
The manpage for soelim (and groff) says of the -I option: "specify a directory
to search for files (both those on the command line
and those named in .so requests). The current directory is always searched
first."
Reality (with foo.ms in the current directory and in
/usr/share/groff/site-tmac/
> I tried setting the point-size in the column specifiers
> (to force tbl to know the font-size), and this worked:
[snip]
How about this?:
.ps 18
.vs 24
.TS
centre;
cBp24
cfBI
l.
ZIMBABWE
.sp .5
Translation
.sp .5
God bless Africa,
Let her fame spread far and wide
Hear our prayer:
May God bless
> Namely: tbl often has to cope with stuff that no-one can know
> the length of until troff has finished with it. In particular,
> equations entered using things like ${x + y} over {u + w}$.
>
> Now, tbl does have a mechanism for creating number-registers
> which will be evaluated by troff, precis
> After a bit of experimentation (use option "allbox" to make the
> widths visible) I believe the behavior can be explained as
> follows:
>
> For calculating the cell widths, all cell contents are inspected
> *independently*. Thus, the apparently longest line ("Let her
> fame spread far and wide
On 20-Aug-08 17:47:47, Tadziu Hoffmann wrote:
>> The following does not come out as I would expect
> [snip]
> After a bit of experimentation (use option "allbox" to make the
> widths visible) I believe the behavior can be explained as
> follows:
>
> For calculating the cell widths, all cell conten
> The following does not come out as I would expect
[snip]
After a bit of experimentation (use option "allbox" to make the
widths visible) I believe the behavior can be explained as
follows:
For calculating the cell widths, all cell contents are inspected
*independently*. Thus, the apparently l
Hi Folks,
The following does not come out as I would expect
(formatting with groff -t -ms ):
.LP
.TS
centre tab(#);
c.
\fB\s[24]ZIMBABWE\s0\fP
\f[BI]\s[18]Translation\s0\fP
.T&
l.
\s[18]God bless Africa,
Let her fame spread far and wide
Hear our prayer:
May God bless us!
Come, Spirit,
>Subject: [Groff] Re: groff bug - eqn
>
It has been mentioned here before that the eqn in the Mac implementation of
groff 1.19.2 has been incorrectly compiled. I have compiled it and it runs.
I'll try emailing you a copy.
Bob Marks
>> In addition to my new MAC laptop (with g
On Sun, Jul 13, 2008 at 08:59:30PM +0200, Werner LEMBERG wrote:
>
> > In addition to my new MAC laptop (with groff v 1.19.2). I have been
> > able to access a MAC desktop with groff v 1.19.1. I ran three
> > different files on the desktop using groff -ms -e filename >
> > filename.ps All three ra
> In addition to my new MAC laptop (with groff v 1.19.2). I have been
> able to access a MAC desktop with groff v 1.19.1. I ran three
> different files on the desktop using groff -ms -e filename >
> filename.ps All three ran without error and produced postscript
> output. All three had extensive
> >> While I still think it's a bug, [...]
> >
> > Why do you think so? At tbl stage it's impossible to expand a
> > string register!
>
> Because it's truncating the string register. I think the correct
> behavior would be to pass it through without truncating.
I don't think so. The correct wa
Werner LEMBERG wrote:
Indeed. tbl sees that you want to format a numeric field, but you
don't give numbers but string registers. To align numbers on the
decimal point it has to interpret the number since this must be done
by tbl itself, and during this process the string register name gets
tr
> > It's something to do with tbl not correctly copying the whole
> > string register name into the troff output.
Indeed. tbl sees that you want to format a numeric field, but you
don't give numbers but string registers. To align numbers on the
decimal point it has to interpret the number since
Ralph Corderoy wrote:
It's something to do with tbl not correctly copying the whole string
register name into the troff output. ... [example deleted] ...
Given tbl is a preprocessor and looks at the text you give to work out
alignment, it's probably not surprising? I suppose tbl's logic coul
Hi Larry,
> As can be seen above, the page number is shifted improperly when its
> string name contains numerals.
It's something to do with tbl not correctly copying the whole string
register name into the troff output. Consider
$ cat foo.tbl
.TS
expand;
l n .
one \*[aa
> The obvious workaround, don't use numbers in string variable
> names, is a hassle.
The problem is that numerical alignment happens at tbl runtime,
not troff runtime, and tbl doesn't have the actual numbers
to work with, only your variable names. I see two solutions:
either use right alignment
Here's a minimal example. See the attached PNG for output.
.\" groff -t -ms tblbug.ms >tblbug.ps
.\" auto-generated cross-refs
.ds xref:controlwaniso:txt Controlling the WAN Isolation State
.ds xref:controlwaniso:pg 79
.ds xref:setipv6fwd:txt Setting IPv6 \%Forwarding
.ds xref:setipv6fwd:pg 80
.ds
> Groff does not compile under gcc 4.1.
Thanks for the report. Please try the current CVS -- I think this has
been reported earlier, and I've already fixed those issues.
Werner
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/m
Groff does not compile under gcc 4.1.
You can find more detailed information at
http://bugs.gentoo.org/show_bug.cgi?id=125666
I thought it would be better to place the url instead of copying it, because
there is more than one person with the same problem, and the page is dynamic,
so you might see
Werner LEMBERG <[EMAIL PROTECTED]> writes:
> > I think a there is a bug in grops as when I try and produce a pdf file
> > from a ps file, gs crashes. All sounds unconvincing, but this worked
> > last May (it works with cvs checkout -D 2005-05-05 groff, isn't cvs
> > great!) and the troff input fi
> I think a there is a bug in grops as when I try and produce a pdf file
> from a ps file, gs crashes. All sounds unconvincing, but this worked
> last May (it works with cvs checkout -D 2005-05-05 groff, isn't cvs
> great!) and the troff input file is trivial.
>
> Here is the troff input file:
>
Hi,
I think a there is a bug in grops as when I try and produce a pdf file
from a ps file, gs crashes. All sounds unconvincing, but this worked
last May (it works with cvs checkout -D 2005-05-05 groff, isn't cvs
great!) and the troff input file is trivial.
Here is the troff input file:
---
> This *shouldn't* have happened, so here's a patch to fix it ...
Applied, thanks.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Hi groffers,
While experimenting with Gaius' dropcap macro, I said ...
pdfroff -ww -M. --no-toc --no-ref dropcap.test > dropcap.pdf
and pdfroff said ...
/usr/local/bin/pdfroff: /^grohtml-info/ {print ".pdfhref Z", $2, $3, $4}:
No such file or directory
This *shouldn't* have happe
64 matches
Mail list logo
