Terrence J. Doyle
2015-01-24 01:06:40 UTC
Well, it looks like I was able to come up with a fix for this after
all. I took a look at the optget()-generated nroff input. For the
problem text line I found this:
%[\-+][\fIwidth\fP[\&.\fIprecis\fP[\&.\fIbase\fP]]](\fIid\fP[:\fIsubformat\fP])\
fIchar\fP\&.
In case it got mangled in the mail you can view the nroff input yourself
by typing:
ls --nroff 2>&1 | less
The problem is that optget() puts a line break at column 80 right in the
middle of a nroff markup. This, of course, confuses nroff.
So, I took a look at optget() to see if I could find where it splits
lines at column 80. It wasn't easy because gdb refused to load ls. But,
I eventually found the spot at line 4093 in src/lib/libast/misc/optget.c.
At first, I tried to think of a way to fix this problem by
preserving the line breaks but make it so they don't appear in the
middle of nroff markup directives. But, I don't understand the optget()
code well enough to really even attempt that.
Then, I realized that this is nroff input. It doesn't have to be
pretty. Making it pretty is nroff's job. So, when optget() is generating
nroff input, let's apply the KISS principle and simply not generate line
breaks. All-in-all, it's a really small change to the code. But, it works.
With this change in place the problem is fixed -- no more runaway
underlining in "ls --nroff". I've attached optget.c.diff for the patch.
Terrence Doyle
all. I took a look at the optget()-generated nroff input. For the
problem text line I found this:
%[\-+][\fIwidth\fP[\&.\fIprecis\fP[\&.\fIbase\fP]]](\fIid\fP[:\fIsubformat\fP])\
fIchar\fP\&.
In case it got mangled in the mail you can view the nroff input yourself
by typing:
ls --nroff 2>&1 | less
The problem is that optget() puts a line break at column 80 right in the
middle of a nroff markup. This, of course, confuses nroff.
So, I took a look at optget() to see if I could find where it splits
lines at column 80. It wasn't easy because gdb refused to load ls. But,
I eventually found the spot at line 4093 in src/lib/libast/misc/optget.c.
At first, I tried to think of a way to fix this problem by
preserving the line breaks but make it so they don't appear in the
middle of nroff markup directives. But, I don't understand the optget()
code well enough to really even attempt that.
Then, I realized that this is nroff input. It doesn't have to be
pretty. Making it pretty is nroff's job. So, when optget() is generating
nroff input, let's apply the KISS principle and simply not generate line
breaks. All-in-all, it's a really small change to the code. But, it works.
With this change in place the problem is fixed -- no more runaway
underlining in "ls --nroff". I've attached optget.c.diff for the patch.
Terrence Doyle
The nroff documnetation for ls (/opt/ast/bin/ls --nroff 2>&1 | nroff
-man | less -s) appears to have a case of runaway underlining. It starts
%[−+][width[.precis[.base]]](id[:subformat])fIchar.
%[-+]][\awidth\a[.\aprecis\a[.\abase\a]]]]]](\aid\a[:\asubformat\a]])\achar\a.-man | less -s) appears to have a case of runaway underlining. It starts
%[−+][width[.precis[.base]]](id[:subformat])fIchar.
This looks OK in my limited experience. I think this might be an
optget() translation error. That might explain the "fI" (fragment of a
t/nroff directive?) before "char".
I'll leave the fix for this one to more experienced hands. It's
rather minor, anyway. But, if there's a bug in optget(), I thought you'd
like to know.
Terrence Doyle
optget() translation error. That might explain the "fI" (fragment of a
t/nroff directive?) before "char".
I'll leave the fix for this one to more experienced hands. It's
rather minor, anyway. But, if there's a bug in optget(), I thought you'd
like to know.
Terrence Doyle