Hi,
On Mon, Nov 27, 2017 at 2:23 AM, Steven Haigh <net...@crc.id.au> wrote:
> On 2017-11-27 05:06, Selva Nair wrote:
>>
>> On Sun, Nov 26, 2017 at 10:49 AM, Jonathan K. Bullard
>> <jkbull...@gmail.com> wrote:
>>>
>>>
>>> This:
>>>
>>> echo "msg This message"
>>> echo "msg will be shown"
>>> echo "msg"
>>> echo "msg on four lines (the third line is empty)."
>>> echo "msg-window the title"
>>
>>
>> That nicely solves the problem of when to display the message.
>
>
> This seems to me to be a horrible solution that has been fixed in other
> solutions for decades.
>
> We're doing string processing at this point - so why can't we use standard
> string formatters:
> \n = new line
> \r = new line
> \t = tab
>
> These have been standard for as long as I can remember - and I'm getting on.
I think you're misunderstanding what program is doing what string
processing (as I did until Selma clarified it for me).
The escapes you describe ("\n", "\r", etc.) are processed by OpenVPN
itself, not by GUIs such as Tunnelblick, and thus would already have
been processed in the text of messages that the GUI receives from
OpenVPN over the management interface. The only way to pass them
through intact for the GUI to interpret them would be to
double-backslash them (e.g. \\n), which might in some circumstances
require yet another level (\\\\n).
You can use multiple-backslash escaping for most characters if you
want to include them in a message. However, commas cannot be included
in strings "pushed" by the server, so we need a way to escape them
that is _not_ processed by OpenVPN, so the escape sequence itself is
passed intact to the GUI. Selma's proposal to use URL encoding (such
as %2C for a comma) does just that.
> This would allow you to combine everything into a single command.
>
> I feel it is a creep in the wrong direction to get the openvpn client to
> piece together your message. If you want to display something, it should be
> pieced together in your script, then sent to openvpn in a single, well
> specified format.
That won't work for "long" messages. (It's what I proposed until I
understood the problems that need to be addressed.)
And by "long" I mean "pretty short" : )
OpenVPN options (including echo and push) are limited to about 255
bytes. Those bytes would have to include the message itself, the
message title, "push", "echo", whatever name we give the message
command, and all separators, quoting and escaping. And some characters
(all in some languages) require multiple bytes. So 255 is a very, very
severe limitation.
So we need a convention for expressing and then combining relatively
short pieces of a message. The "msg" and "msg-n" proposal does that:
it allows long lines to be created (using "msg-n"), and allows
multi-line messages without escapes ("msg", with it's implied
newline).
Best regards,
Jon
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
