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 On 1/10/15 7:27 PM, Terrence J. Doyle wrote: > > 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 > with the -Z option in this phrase: > > %[−+][width[.precis[.base]]](id[:subformat])fIchar. > > In src/lib/libcmd/ls.c the optget() text for this phrase appears as: > > > %[-+]][\awidth\a[.\aprecis\a[.\abase\a]]]]]](\aid\a[:\asubformat\a]])\achar\a. > > 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 _______________________________________________ ast-developers mailing list ast-developers@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-developers