In Debian bug #733852, Vincent Lefevre wrote:
> When one types Ctrl-V Ctrl-J (to make a ^J control character appear
> on the command line), dash outputs a spurious "> " string (one by
> ^J occurrence) once the command is validated. For instance:
> $ echo "ab^Jcd^Jef"
> > > ab
> cd
> ef
> $ true "ab^Jcd^Jef"
> > > $
> where the ^J has been entered with Ctrl-V Ctrl-J.
I think this is a normal consequence of using the kernel line editing
("canonical mode", ICANON) instead of something like libedit or
libreadline. In the sequence of bytes returned from read(), Ctrl+V
Ctrl+J looks the same as <Enter>.
One difference is that the kernel returns (parts of) one line in a
single read() call, which could be used to distinguish between the two
kinds of newline. This is not fully reliable because a newline at the
last byte of a read call that fills the buffer completely cannot be
analyzed this way; both Linux and FreeBSD permit longer lines than their
advertised {MAX_CANON} so the problem cannot be avoided with a
{MAX_CANON}+1 buffer.
I expect that the extra ugliness caused by this incomplete check will
not be worth it. It would be better to enable libedit or to use a
version of linenoise (link it statically to avoid the impact on fork()
performance).
By the way, you can also have a "spurious" "$ ":
$ echo a^Jecho b
a
$ b
$
--
Jilles Tjoelker
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
