On 07/06/16 11:25, Herbert Xu wrote:
If the very first character later gets zeroed, you'd be zeroing
the character after the CTLESC, leaving the CTLESC in the value
to be assigned to the last variable of read.
Ah, I see. Thanks for the explanation. While trying to make it misbehave
I found that rmescapes removes trailing CTLESC, and readcmd_handle_line
calls rmescapes before the trailing CTLESC gets a chance to cause
problems. I was now still only able to see the problem when adding some
extra debugging statements.
If you got rid of the very first q=p assignment it should just work.
There is a later q=p assignment too that gets performed after CTLESC has
been skipped. That one also isn't going to cause problems in practice,
since it only gets executed when a character is both IFS and IFS
whitespace, but when called from readcmd_handle_line, there's never
going to be escaped IFS whitespace.
Thanks. I've fixed up the buglet causing the failures:
The results are a lot better now, but I did spot a problem:
src/dash -c 'X="x "; echo $X'
This is supposed to print "x\n", but the IFS breakup of $X generates two
words, one "x", one " ", meaning "x \n" gets printed instead. I think
this is intended to get fixed up in the if (ifsspc) block, but that
block doesn't get executed when there are no more characters after the
spaces.
Cheers,
Harald van Dijk
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
