Re: PATCH: refactor memstream for "print -v"

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Mon, 04 Jan 2016 23:18:30 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> - Should "print -v foo bar" write the trailing newline into $foo ?  In the
>   patch below I've chosen to make -n implicit with -v.  This does not
>   involve "printf" which always needs an explicit newline.

That's probably reasonable --- it would only become crucial which way it
was defined if you were able to append to the variable by some such
means, so needed the intervening newlines, but there's no call for that.

> - I did not change any behavior of the -z / -s / -S options, or at least
>   have not intentionally done so.  However, there have never been any
>   Test/B03* cases for those.

Interactive behaviour is much more lightly tested, but there is now some
prior art for both history and ZLE.  It probably goes in those areas.

> - I believe that prior to this patch, in the case of simulating memstream
>   with a temp file, errors closing the tempfile caused an error message
>   and a nonzero return even though the history/bufferstack/parameter was
>   already correctly stored.  I have not made an effort to fix that.

Probably not a big issue.  An error closing the temp file suggests
something rather nasty is screwed up.

> - I note in passing that "print something >&-" is explicitly not an error,
>   but "print -u1 something >&-" IS an error.  Also unchanged here.

In the second case we've explicitly been told to "do something" with the
fd, which happens to be dup'ing and fdopen'ing it.  There's no such code
in the first place, and there doesn't seem any point in making the
second case silent.  I suppose we'd have to detect bad writes in lots of
places to pick up errors in the first case, but that would probably be
the right thing to do in principle.

pws