From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 753 invoked by alias); 20 Feb 2015 09:54:47 -0000 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-Seq: 34583 Received: (qmail 27337 invoked from network); 20 Feb 2015 09:54:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f5-b7fc86d0000066b7-8a-54e703cbd401 Date: Fri, 20 Feb 2015 09:54:06 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: PATCH: parse from even deeper in hell Message-id: <20150220095406.4e3ebb9d@pwslap01u.europe.root.pri> In-reply-to: <54E6B5C3.1000104@eastlink.ca> References: <20150219101315.477f7f95@pwslap01u.europe.root.pri> <20150219220311.7dfdc4ec@ntlworld.com> <54E6B5C3.1000104@eastlink.ca> 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+NgFlrCLMWRmVeSWpSXmKPExsVy+t/xy7qnmZ+HGCz+wWtxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4MnY2nGUumMxV0flGtIGxm6OLkZNDQsBE4v/RZ+wQtpjEhXvr 2boYuTiEBJYySrRO/AzlLGGSWPxjOQuEs41R4uHkr2AtLAKqEvM2LWYFsdkEDCWmbprNCGKL CIhLnF17HqiBg0NYwEhi8wUxkDCvgL3Eqq03wVo5BbQlJl77yAZiCwm8YZZY+ysExOYX0Je4 +vcTE8RF9hIzr5xhhOgVlPgx+R4LiM0soCWxeVsTK4QtL7F5zVtmiDnqEjfu7mafwCg0C0nL LCQts5C0LGBkXsUomlqaXFCclJ5rpFecmFtcmpeul5yfu4kRErJfdzAuPWZ1iFGAg1GJh1fg 0rMQIdbEsuLK3EOMEhzMSiK8ZReBQrwpiZVVqUX58UWlOanFhxiZODilGhhDPB/XfbXzeLCU f/lih5CM1zVSs91nK0RIa5Us9lwZ8LG9xKQjXfW2xUyJXRJmpmkpN/33/vc7tSzBfP39yQtK 2HJ3ucmWif8PctpV+3OR5t2UmvpN7r+jcmVs/xz8fODdopWilz8npPjrztrJ4Jf+p7pGr7tQ Qchz/zyxAMXp13nc/2m18SmxFGckGmoxFxUnAgAvFR6zNwIAAA== On Thu, 19 Feb 2015 20:19:15 -0800 Ray Andrews wrote: > Would some kind soul explain (if an explanation is possible) why the > original string is not just saved verbatim? (Or maybe after history > expansion is handled). Why would a line in history not just be what it is? That's a good question, and while we're probably stuck with the current behaviour --- history files need to be shared between different versions of the shell --- it would be good to know why. The reason will probably be one of - It just got forgotten about. It works within any version of the shell because the string is well-defined; it's only when we add a token, as I did yesterday, that we get incompatibilities. So no one noticed it wasn't really pukka. - It's so we can get embedded zero bytes. Zsh attempts to treat these internally as ordinary characters, rather than string terminators. However, they're ordinary characters in file text, too, so it's not clear this is a good reason. Further, we already escape some characters in an ad hoc fashion, notably newlines, so there's no reason we shouldn't do that here, too. The mailing list archive from the dim and distant past may cast light upon this but I think current folk memory isn't up to it. pws