On Tue, May 30, 2006 at 12:26:45AM +0200, Michael Kerrisk wrote:
> Justin,
>
> I feel this page could be improved further. Please:
>
> * read "man 3p getsubopt" and "info getsubopt".
As noted in the manpage, I have done so.
> Make your terminology consistent with them (epsecially the 3p doc;
> e.g., use "token" and "value")
> * send me a test program that you've used to verify
> how getsubopt works. (Don't worry about including it
> in the man page -- I may do that later.)
Attached.
> > .TH GETSUBOPT 3 "2006-05-26" GNU
> > .
>
> What are these dots doing?
Best-practice mentioned in roff.7:
o Never include empty or blank lines in a roff document. Instead,
use the empty request (a line consisting of a dot only) or a line
comment .\" if a structuring element is needed.
> > .SH SYNOPSIS
> > \fB#define _XOPEN_SOURCE 500
>
> I prefer that you use the ".BI" style for
> prototypes (see fcntl.2); please change this.
You'll be happy to know that I recently started using them for argp.3.
BTW, where are \f[RPBI] documented?
I dislike .{nf,fi}, since it assumes a given terminal width. By the
way, why does nroff |less seem to assume 80 character width?
Re: your previous question ("Re: Fixes from the Debian diff...",
[EMAIL PROTECTED])
groff_diff.7:
In GNU troff, as in UNIX troff, you should always follow a sentence
with either a newline or two spaces.
Also:
groff.7
In text paragraphs, it is advantageous to start each sentence at a
line of its own.
roff.7
o Start each sentence on a line of its own, for the spacing after a
dot is handled differently depending on whether it terminates an
abbreviation or a sentence. To distinguish both cases, do a line
break after each sentence.
> > \fBNULL\fP-terminated list of accepted parameters.
>
> Please don't format "NULL".
Done; could you provide a quantitative distinction between things
which should{,n't} be formatted?
> > The first equal sign in a parameter (if any) is interpreted as a
> > separator between the name and the value of that parameter. The value
> > extends to the next comma, or (for the last parameter) to the end of
> > the string. If the name of the parameter matches a known name from
> > \fItokens\fP, and a value string was found, \fBgetsubopt\fP() stores
> > to
>
> As noted for another of your pages, "stores to" isn't good grammer;
>
> Better: "store the address of that string in *valuep"
Is your objection to the order of the clauses, or to the preposition?
Justin
/* make CFLAGS='-W -Wall -O3 -g -std=gnu99' getsubopt */
#define _GNU_SOURCE
#include <stdlib.h>
#include <assert.h>
#include <stdio.h>
int main(int argc, char **argv)
{
char *const tok[]={
"foo",
"bar",
"baz",
NULL,
};
if (argc!=2) {
fprintf(stderr, "Usage: %s <suboptstring>\n", *argv);
exit(EXIT_FAILURE);
}
for (char *s=argv[1]; *s; ) {
int ntok=-1+sizeof(tok)/sizeof(*tok);
int ret;
char *val;
if (-1==(ret=getsubopt(&s, tok, &val))) {
printf("Failed to match to token: %s\n", val);
continue;
}
assert(ret<ntok);
printf("Matched to token %d (%s); value: %s\n",
ret, tok[ret], val);
}
exit(EXIT_SUCCESS);
}
