Usman Akinyemi <usmanakinyemi202@xxxxxxxxx> writes:
>> Is there a need for a registry of canonical os-version strings? One
>> reason why you would want this user-settable (as opposed to being
>> derived from "uname -s") is that a system that is presumably the
>> same in end-user perception can call itself in different names (your
>> Windows/MINGW64 example) and having the users set it to a string
>> chosen from a small repertoire, the other end would be able to
>> identify them more easily. I do not think it is a necessarily a
>> good idea to limit what value the users can set to this
>> configuration variable, but at least with a published guideline on
>> calling various types of systems (and an explanation on the reason
>> why we publish such a guideline), users would make an informed
>> decision when picking what string to send.
>
> We plan to implement another config option `osVersion.format`, which
> allow users to fully customize the string sent to the other side using
> placeholders,
Sorry, you lost me.
I was wondering if we want to (informally at first) make it _less_
flexible, so that we can prevent people from being "creative" when
the value of being creative is negative. Adding even more ways to
customize the string to subject the receiving/inspecting end to more
unnecessary variations to call the same thing in different names is
the last thing we want to see in that context, isn't it?
If you have "any random string goes" configuration mechanism, it is
pretty much game over. You do not need to add an elaborate .format
mechanism to let users throw random garbage at the other side of the
connection.
>> > +# Trim and replace each character with ascii code below 32 or above
>> > +# 127 (included) using a dot '.' character.
>> > +# Octal intervals \001-\040 and \177-\377
>> > +# corresponds to decimal intervals 1-32 and 127-255
>> > +test_redact_non_printables () {
>> > + tr -d "\n" | tr "[\001-\040][\177-\377]" "."
>> > +}
>>
>> Just being curious. Do we need to worry about carriage-returns not
>> just line-feeds, and if not why?
> The function `tr "[\001-\040][\177-\377]" "."` already replace the
> carriage-returns with "."
That is exactly my point. LF are stripped; I do not see a sensible
reason why shouldn't CR be removed the same way.
Thanks.
