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"
cd
ef
$  true "ab^Jcd^Jef"

where the ^J has been entered with Ctrl-V Ctrl-J.

I'm wondering whether this problem comes from an old behavior that
no longer works or something that has actually never worked, where
the "> " should have been some prompt like with busybox sh.

In Debian bug #733852, Vincent Lefevre wrote:
("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
$

I'm feeling generous so this patch works for me.

It fixes this problem too.

Thanks,

---8<---
Do not print a prompt if there is still input left over in the
input buffer.

Add a noinline attribute to setprompt while doing this as otherwise
gcc will produce horrendous output.

Reported-by: Vincent Lefevre <vincent@vinc17.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/src/parser.c b/src/parser.c
index 412e876..4e8daf7 100644
--- a/src/parser.c
+++ b/src/parser.c
@@ -1705,8 +1705,7 @@ synerror(const char *msg)
 	/* NOTREACHED */
 }