From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alexander.turenko@tarantool.org>
Received: from smtp44.i.mail.ru (smtp44.i.mail.ru [94.100.177.104])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 24E0A401A41
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 25 Oct 2019 12:53:22 +0300 (MSK)
Date: Fri, 25 Oct 2019 12:53:12 +0300
From: Alexander Turenko <alexander.turenko@tarantool.org>
Message-ID: <20191025095311.onkz36woc2bbzc5u@tkn_work_nb>
References: <20191004074926.17329-1-gorcunov@gmail.com>
 <20191004074926.17329-4-gorcunov@gmail.com>
 <20191025000022.msnkmuyh3mydxxim@tkn_work_nb>
 <20191025074012.GC2511@uranus.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20191025074012.GC2511@uranus.lan>
Subject: Re: [Tarantool-patches] [PATCH 3/7] box/console: Add explicit
	output EOS mapping
List-Id: Tarantool development <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: tml <tarantool-patches@freelists.org>, tarantool-patches@dev.tarantool.org

On Fri, Oct 25, 2019 at 10:40:12AM +0300, Cyrill Gorcunov wrote:
> On Fri, Oct 25, 2019 at 03:00:22AM +0300, Alexander Turenko wrote:
> > 
> > Should not we wait for ';\n'?
> 
> Strictly speaking ; is only eos, the newline is needed for terminal
> driver. But currently what we have might confuse a user, so I think
> you are probably right. Need to think and revisit this moment. Thanks!

We use this approach for reading of a client input on a remote server:
see client_read() in src/box/lua/console.lua ('\r' here to handle telnet
connections, see fa1aa01e49f323557fc981f7a76d85f99a9c7990).

Those delimiter was introduced before implementing local_check_lua(),
which works on a client side (both for local console and a client for a
remote console): when a delimiter is not set, we read input line by line
and try to parse it as a Lua statement using loadstring().

There are some flaws however:
https://github.com/tarantool/tarantool/issues/4082

I suspect the latter approach is not usable for cases where we have no
Lua interpreter on a client side (say, for test-run); I mentioned it to
provide more broad information.