From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 53c5d35f for ; Fri, 21 Dec 2018 02:58:09 +0000 (UTC) Received: (qmail 26653 invoked by alias); 21 Dec 2018 02:57:51 -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: List-Unsubscribe: X-Seq: 43919 Received: (qmail 7714 invoked by uid 1010); 21 Dec 2018 02:57:51 -0000 X-Qmail-Scanner-Diagnostics: from munnari.oz.au by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25112. spamassassin: 3.4.2. Clear:RC:0(202.29.151.3):SA:0(-1.9/5.0):. Processed in 1.888276 secs); 21 Dec 2018 02:57:51 -0000 X-Envelope-From: kre@munnari.OZ.AU X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | From: Robert Elz To: Martijn Dekker cc: zsh-workers@zsh.org Subject: Re: The big kre zsh bug report In-Reply-To: <18f684a8-2fec-4ebe-a63e-cf6688ae519f@inlv.org> References: <18f684a8-2fec-4ebe-a63e-cf6688ae519f@inlv.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Dec 2018 09:28:22 +0700 Message-ID: <4801.1545359302@jinx.noi.kre.to> Date: Thu, 20 Dec 2018 22:25:12 +0000 From: Martijn Dekker Message-ID: <18f684a8-2fec-4ebe-a63e-cf6688ae519f=40inlv.org> =7C Robert Elz a.k.a. kre (author of NetBSD sh) definitely not author, but I am doing most of the current maintenance (and a few upgrades). =7C All further quoted text below is from kre... (Note his test suite o= utput=20 =7C doesn't quote the '-c' option argument, but the tests are executed = as if=20 =7C it were quoted with single quotes.) Yes, sorry about that, the tests are run by code that almost everyone wou= ld like to replace, and which is mostly not maintained (but, aside from most= ly cosmetic issues like this, does work)... That's where that output comes= from. =7C Yes, I don't think the =22=24=7Bop=7D=22 being quoted has anything = to do with it.=20 =7C It fails only at the second loop iteration, so with '-' as the oper= ator. =7C =7C So it doesn't like this: =7C =7C =24 zsh --emulate sh -c 'echo =24(( =24(echo 9) =24(echo -) =24(ech= o 2) ))' =7C zsh:1: bad math expression: operator expected at =602 ' =7C =24 zsh --emulate sh -c 'echo =24(( 9 =60echo -=60 2 ))' =7C zsh:1: bad math expression: operator expected at =602 ' I thought I corrected this one, either later in the big message, or a=20 subsequent one. The issue there is the use of echo where the first arg starts '-' which is definitely an undefined area (the AT&T idiots who broke the original Bell Labs echo have a lot to answer for=21) I am going to change my tests to use printf instead. There is no issue here with zsh. =7C =24 zsh --emulate sh -c 'set -- a b c; echo =24=7B=23:-99=7D' =7C 2 =7C =7C That should be 3, so this is a bug. Dealing with =23 in parameter expansions is painful, as it has so many possible meanings, which need to be figured out by context (not all of which have defined results). But where it can reasonably be =24=7B=23=7D (with perhaps some extra modifiers) it really ought to be. =7C Confirmed. Modernish identifies this as a shell quirk (QRK_IFSFINAL= )=20 =7C because the POSIX spec is quite ambiguous on this, so I was unable = to=20 =7C confirm that it is actually a bug and not a legitimate behaviour va= riant. It is not supposed to be ambiguous any more - it used to be once. In XCU 2.6.5: The shell shall treat each character of the IFS as a delimiter and use th= e delimiters as field terminators to split the results of parameter expansion, command substitu= tion, and arithmetic =7C expansion into fields. =5B...=5D b. Each occurrence in the input of an IFS character that is not IFS white= space, along with any adjacent IFS white space, shall delimit a field, as describ= ed previously. The std (consistently) uses =22delimit=22 to mean =22terminate=22 not =22= separate=22 but=20 some readers misunderstand, and assume it means =22separate=22 (as in, oc= curs=20 between) The intent is that when something is being collected (a field here, a token in the lexer, ...) and the text says the next char =22delimits the = xxx=22 it means that whatever was being collected is finished, what follows depends upon what appears (if anything) - the delimiting character does not, by itself, create anything following. This is particularly confusing with field splitting, as =22IFS=22 is used= , and the 'S' in that is =22separator=22 which is preisely what it is not. Bu= t the name is historic. =7C _____________________ =7C > Next, zsh apparently does not implement the posix =7C > required -h option. Nor do we, but we at least allow =7C > it to be set and cleared .... =7C =7C I'm not sure that allowing it to be set and then not doing what it = =7C promises is better than not allowing it to be set at all. If anything actually differs when that nonsense (implemented as specified, which I am not sure anything does) is turned on, it would be something of a surprise, and most likely break everything. It is just that posix says that the option is supposed to exist, so some script might turn it on. Why I could not guess... =7C This issue caused me headaches when implementing match() on moderni= sh. I=20 =7C was given the impression that passing backslash-quoted characters=20 =7C through variables for use in 'case' patterns was one of those thing= s=20 =7C that POSIX doesn't really specify one way or another. Of course I w= ould=20 =7C much prefer the behaviour of bash, dash, and NetBSD sh. The pattern matching part of posix is due a rewrite (there is an open iss= ue with some potential fixes) - the intent is that it should work as you des= cribe, but it is hard (but not impossible) to read the current text to mean that= . =7C _____________________ =7C Various other tests showed that zsh cannot handle file descriptors = >9.=20 =7C Not really a bug as POSIX permits that limitation, but: =7C =7C > And again, this test fails the same way with --emulate bash =7C > and bash certainly permits fds > 9=21 =7C =7C So you could consider this a feature request. The '9' limit was created when the per-process file descriptor limit was 16... The shell needs a few fds for itself, so ... These days programs have access to lots more fds, so should sh scripts. kre