I generally agree with your first point but not with the second:
>
> Change the SYNOPSIS in line 19270 to
> iconv [-cs] -f frommap -t tomap [file ...]
> iconf [-cs] [-f fromcode] [-t tocode] [file ...]
Is this really equivalent to what the sentence on line 19306f says?
There it says that other combinations are undefined. This syntax could
be interpreted that they are invalid. Does this make a difference?
I'm not sure whether it is the best idea to introduce the new *map
names. Look at your proposed changes:
> Replace lines 19288 to 19296 with:
>
> -f fromcode
> Identify the codeset of the input file. If the option-argument
> does not contain a slash,
This would have to be written like
-f fromcode
Identify the codeset of the input file. The option-argument must
not contain a slash character. [...]
and then later
-f frommap
Identify the codeset of the input file. The option-argument must
contain a slash character. [...]
I find this rather awkward. I realize that you want to distinguish
between tocode and tomap to handle your second inconsistency. But since
I disagree with your second point I don't see the need.
Instead I think the parameter names should be renamed to "fromname" and
"toname". The -c description should be changed to
-c Omit any invalid characters from the output. When -c is not used,
the results of encountering invalid characters in the input stream
(either those that are not valid members of the charmap or codeset
named by /fromname/ or those that have no corresponding value in
charmap or codeset named by /tocode/) shall be specified in the
system documentation. The presence or absence of -c shall not
affect the exit status of iconv.
Similarly for -s. The other options only change as in
s/\(from\|to\|)code/\1name/.
Now to your second inconsistency. I don't think it really is one. Yet,
the iconv utility implementation does provide a feature the interface
doesn't have. This does not mean that there is something wrong. There
is no requirement for that anywhere. Utilities can certainly require
functionality which isn't in the standardized interfaces.
This means that, if you want to implement the iconv utility with the
iconv interface, your iconv implementation has to have some non-standard
feature. That's how I implemented it.
The reason why I don't want to see the change you proposed is that is
severely reduces the usefulness of the -c option (BTW you didn't want to
change the -s option?) I for once know that users are looking for the
definitive reaction if the iconv utility in such a situation. There are
wrong-encoded files and leaving it up to the implementation to decide
how the utility reacts prevents writing portable scripts. It would be,
for instance, possible to abort the conversion altogether. This is what
my implementation does in the absence of this flag.
In summary:
- I'd resolve issue #1 by replacing the *code names with *name names and
adjust the text appropriately. I could provide appropriate editing
instructions if this is accepted.
- I'd do nothing on issue #2 since the current spec is what users want
and need and it does not contradict the rest of the standard anywhere.
BTW: I just realized that the description of the -l parameter needs to
be rewritten. The presence of charmaps make the requirement
unfulfillable. The requirement should only include writing all codeset
names to standard out and explicitly leave out the charmap names.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
signature.asc
Description: This is a digitally signed message part
|