From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12760 invoked by alias); 23 Mar 2016 06:48:33 -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: 38209 Received: (qmail 12882 invoked from network); 23 Mar 2016 06:48:31 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=usApA4q4PecMBl2EKI6I8Qv4mbVnlCHLQP3PDZRdCP0=; b=NJY/ghRkzm15Ouw7+5JSH6Bh/djf8jaYn9fxlAYUWb33lZr4zUROzewxoSYPZmyJvI 7kpAPUmCujT16VCl4z069CnSbh4S3xQYq+nvhrXH4mLATJB6MIwIXYoHgmkQnpLcEAYc uFWF4Q7ySAFbyWlZP07tl5Fnco6vFqOEhwpi2yHf47QTAPxPXDSqoGc7VZ1V+a9bFv6/ 3p7ahgsh4qIBpZnj1/qAPSgu6iGWkrTkLvJuM610fsb8b53A9sU+V0E/ATINm7Rdt1WC wLTEGtC4QKUipl8pNvEpMHRiFla2hwIA18erINV58abndD9MP20w/JakP5mw/VYwG/hZ XTYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=usApA4q4PecMBl2EKI6I8Qv4mbVnlCHLQP3PDZRdCP0=; b=eUPEMfsMkbhjEeQzN5SUkDuAFpy0+BEnY2z9D0sUZmleS0lQnsSuuL5FBl9S7CcYy1 5oZ0SJ5FyNoiOHbzEhxrrTX4aXvlOhQtsELRDLgxNQU/rXSEXyWsADI4AxfUxaqWvDpg 9lUCuwf/0qSHuzigKtEd6zfhP4RV7cSEBNzZn6Vvuf3HYZalF4RAHb7o9Xu0sERlD910 lxyITHVcpcsWF8JxWi1toljjFamrAsgJX0LC8LYlx7FKB5IVGJv2+m/Y/0vnuqdpWD10 sFnuTDvtimtwzE7QVWckiklPleWgbrfckBJ3B/PNYWMaROjp48OPB8TWn67FGgc+gRmi tZWw== X-Gm-Message-State: AD7BkJLXuoEL16/KPo2DS+Y3Idfs34fP1C/kFr58kSDq72YSWJId8iseoPFvcSE2k5H6HfpTD9NM8YbLdY/8bg== MIME-Version: 1.0 X-Received: by 10.194.223.104 with SMTP id qt8mr1361498wjc.11.1458715254877; Tue, 22 Mar 2016 23:40:54 -0700 (PDT) In-Reply-To: <56F1FF5F.6060907@redhat.com> References: <56F1C3D7.6020800@redhat.com> <56F1FF5F.6060907@redhat.com> Date: Tue, 22 Mar 2016 23:40:54 -0700 Message-ID: Subject: Re: zsh -n does not detect incorrect associative array declaration From: Bart Schaefer To: Zsh hackers list Cc: Paul Wayper Content-Type: text/plain; charset=UTF-8 On Tue, Mar 22, 2016 at 7:28 PM, Paul Wayper wrote: > On 23/03/16 11:20, Bart Schaefer wrote: >> >> Technically, the shell is ALSO prohibited by NO_EXEC from executing >> the "typeset" command, and therefore can't possibly know that "fn" >> represents an associative array in the first place. >> >> The NO_EXEC option is only useful for the most rudimentary of syntax >> checks. It cannot detect/predict execution-time inaccuracies. > > Given that situation, should we update the zsh manual to point out that > the -n option cannot check the syntax of commands that are evaluated, so > that this is more explicit? I'd be happy to write such an update and > push it if you'd prefer that. I don't have a preference here, but I don't think there's any reason for the zsh manual to be any more explicit than the manual for any other shell; for example bash: -n Read commands but do not execute them. This may be used to check a shell script for syntax errors. This is ignored by interactive shells. > However, I don't see why you can't at least check that the syntax is > correct for things that don't use evaluation. That by far must be the > majority of such cases. There's nothing *syntactically* wrong with fn=(foo_key foo_val bar_key) Even when executing commands normally, the syntax analyzer does not know that the assignment will fail if there are an odd number of values in the list. That's a semantic error discoverable only when the assignment is performed. The shell language is interpreted, not truly compiled, so parameter type information is not used in syntax analysis. Plus, you're still ignoring the fact that the shell doesn't know "fn" is associative because it was not allowed to interpret the foregoing "typeset" command. Aside: In your original zsh_bad_array.zsh example you can tell that it was a semantic/runtime error rather than a syntax error because when the script was run WITHOUT "-n" the statements before and after the bad assignment were still executed. An actual syntax error would have aborted the entire script, probably with a "parse error" printed to stderr. Contrast this with ksh where associative array assignments look like fn=( [foo_key]=foo_val [bar_key]= ) There the parser doesn't need to know the type of fn because the association is explicit in the format of the parenthesized list. If we ever get around to implementing that bit of ksh syntax your assertion would become valid. (But in that case the assignment forcibly changes the type of "fn" to become an associative array so the typeset is irrelevant.)