On 2019-11-11 09:28, Corinna Vinschen wrote:
> On Nov 11 08:30, Brian Inglis wrote:
>> On 2019-11-11 02:19, Corinna Vinschen wrote:
>>> On Nov 11 10:13, Corinna Vinschen wrote:
>>>> On Nov 10 09:14, Brian Inglis wrote:
>>>> The patch idea is nice. Two nits, though.
>>>> Please shorten the commit msg summary line and add a bit of descriptive
>>>> text instead.
>>
>> Sorry, I forget and don't notice longer than standard messages, from using
>> 120x60 or larger windows.
>>
>>>>> ---
>>>>> winsup/utils/regtool.cc | 13 ++++++++++++-
>>>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/winsup/utils/regtool.cc b/winsup/utils/regtool.cc
>>>>> index a44d90768..ddb1304cd 100644
>>>>> --- a/winsup/utils/regtool.cc
>>>>> +++ b/winsup/utils/regtool.cc
>>>>> @@ -167,7 +167,9 @@ usage (FILE *where = stderr)
>>>>> " users HKU HKEY_USERS\n"
>>>>> "\n"
>>>>> "If the keyname starts with a forward slash ('/'), the forward
>>>>> slash is used\n"
>>>>> - "as separator and the backslash can be used as escape
>>>>> character.\n");
>>>>> + "as separator and the backslash can be used as escape character.\n"
>>>>> + "If the keyname starts with /proc/registry{,32,64}/, using forward
>>>>> or backward\n"
>>>>> + "slashes, allowing path completion, that part of the prefix is
>>>>> ignored.\n");
>>>>
>>>> Is that really essential user information?
>>
>> Absolutely essential!
>>
>>>> I assume this behaviour is something you just expected to work but then
>>>> didn't. With your patch it now works as you expected. So it's kind of
>>>> a bugfix, rather than a change of behaviour the user needs to learn about.
>>
>> To those with similar background or experience it may appear that it should
>> be
>> supported, but hasn't been until now.
>>
>> It is definitely not expected behaviour, given how regedit, reg, etc. expect
>> only hive paths, and how the the current regtool --help reads, clearly
>> expecting
>> Windows style backslash separated registry paths, probably pasted within
>> single
>> quotes. That expectation is changed somewhat by the forward slash sentence.
>> Further changes to expectation needs more documentation.
>>
>>>> The above text is, IMHO, more confusing than helpful to a user just
>>>> asking for regtool --help. I'd just drop it.
>>
>> It needs documented because it can not in any way be inferred from the
>> existing
>> regtool ---help, and would not be expected, that it should work. It was never
>> previously supported or seen as helpful or necessary, so it should be seen
>> as a
>> non-obvious "surprising" addition, in the opposite sense to "least surprise".
>>
>> Please someone suggest better wording for the help, as that is the only
>> documentation available, and is needed, to update existing and inform new
>> users.
>> Like the code, I tried to maintain the style of the existing help.
>>
>> As an alternative, how about:
>> "To support path completion, a keyname prefix of /proc/registry{,32,64}/ is
>> ignored."
>
> Ok, we can add something to the help text, but the text still sounds
> confusing, even the altenative one. I think the reason is the negative
> expression "ignore" here. Why not express this in a positive way like
> this:
>
> "Use the /proc/registry{,32,64}/ registry path prefix to utilize path
> completion."
>
> Something like that anyway.
Maybe something may be misinterpreted from your consideration of International
English wording that is not even considered in my native English; "is ignored"
is passive voice but not negative in English, and neither does it appear to be
so in Deutsch (via Google): "Zur Unterstützung der Pfadvervollständigung wird
das Schlüsselnamenpräfix /proc/registry{,32,64}/ ignoriert."
Please advise if you can think why there is a wording issue.
I found the doc/utils.xml entry and added the improved sentence to both,
changing the example to be consistent and the better choice to exemplify the
alternative, and better fit the UG, man pages, and --help.
Please review the resubmission.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
