Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f4-f79026d00000418a-d1-568b91697f26 Date: Tue, 05 Jan 2016 09:48:21 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: PATCH: refactor memstream for "print -v" Message-id: <20160105094821.307cca71@pwslap01u.europe.root.pri> In-reply-to: <160104231830.ZM20279@torch.brasslantern.com> References: <160104231830.ZM20279@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsVy+t/xq7qZE7vDDB618FgcbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujJ7dF9gKZvBVdH18xdrAOJm7i5GTQ0LARGLtkrNMELaYxIV7 69m6GLk4hASWMkpM/rKZEcKZwSSxdMFGdgjnNKPEqtm7mCCcM4wSy//fYQHpZxFQlViz7yOY zSZgKDF102xGEFtEQFzi7NrzYHFhAVOJb/OPg9m8AvYSN+bcBNvNKWAlcaTvNhuILSRgKTHv 7XNmEJtfQF/i6t9PUPfZS8y8coYRoldQ4sfke2BzmAW0JDZva2KFsOUlNq95ywwxR13ixt3d 7BMYhWchaZmFpGUWkpYFjMyrGEVTS5MLipPScw31ihNzi0vz0vWS83M3MUIC+ssOxsXHrA4x CnAwKvHwcrzsChNiTSwrrsw9xCjBwawkwitY2B0mxJuSWFmVWpQfX1Sak1p8iFGag0VJnHfu rvchQgLpiSWp2ampBalFMFkmDk6pBsZVZrenptlo+ESftCzZK3xDbNGL4DNcRjt3vV59jtH2 T9n8VTcZN0y/Zz6Fb81N0+J9Z7cuL5jpUhe5P2l9a0q8afDkhuLd2kyC5897bV4mlnVY23Zz Vdb9fN76FfHnt6ofnqXG5DBNdmEQ29GP3Ub7g1NmaT+YV25YyH98h1/5mdpJubZJ2zqUWIoz Eg21mIuKEwF6ZxTGZAIAAA== X-Seq: zsh-workers 37505 On Mon, 04 Jan 2016 23:18:30 -0800 Bart Schaefer 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