From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-19936-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 16947 invoked by alias); 1 Mar 2015 16:50:18 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 19936
Received: (qmail 7246 invoked from network); 1 Mar 2015 16:50:05 -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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,
	T_FSL_HELO_BARE_IP_2 autolearn=ham version=3.3.2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
	t=1425228234; bh=NTIjNWO3ZKhqFQUswF0/N2Rwht9otOhmJi2Y71pQyfE=;
	h=From:To:In-Reply-To:References:Subject:Date;
	b=XtFs1NLF1slPWWjhdENl62T0xJt+oqug1XfBlJvHYhZDet6lrJ8uiwf63xFo8dN/e
	 8XCM0Lc+9sz8zjkiwLPTK1qccMyaZ8rPZO/ULRM4TBa0GT89a8leLIadxg6+Qi4j+9
	 68yyXRHyLqQb6gIo13U0B00vDacBv9A5wPzCZpn0=
From: ZyX <kp-pav@yandex.ru>
To: Ray Andrews <rayandrews@eastlink.ca>,
	zsh Users <zsh-users@zsh.org>
In-Reply-To: <54F33934.2070607@eastlink.ca>
References: <54F33934.2070607@eastlink.ca>
Subject: Re: grammar triviality with '&&'
MIME-Version: 1.0
Message-Id: <13666281425228233@web7o.yandex.ru>
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Date: Sun, 01 Mar 2015 19:43:53 +0300
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=koi8-r

01.03.2015, 19:09, "Ray Andrews" <rayandrews@eastlink.ca>:
> I notice that zsh is quite tolerant as far as most
> line wrap situations go, except for this:
>
> ššššš[ -e file1 ] &&
> ššššš[ -e file2 ] &&
> šššššecho 'both files exist'
>
> ... good
>
> ššššš[ -e file1 ]
> ššššš&& [ -e file2 ]
> ššššš&& echo 'both files exist'
>
> ... syntax error, but we can fix it like this:
>
> ššššš[ -e file1 ]\
> ššššš&& [ -e file2 ]\
> ššššš&& echo 'both files exist'
>
> I'm wondering why the line continuation is strictly necessary.
> IOW, why doesn't the parser permit the '&&' on a new line?
> I've been trying to come up with something that would
> cause an ambiguity if it were permitted, but can't find anything,
> but I doubt the rule would be there otherwise.

Each of the lines is a sequence of `zle self-insert` followed by `zle accept-line`. In first and third cases it is possible to, based on parser state, determine that more input is required. In the second it is a complete command on the first line.

Note that zsh is a shell. Its main purpose is parsing user input, *not* scripts. What you ask will require special-casing script parsing (note: things like aliases or BANGHIST are processed prior to the time string is feed to the parser).

Note 2:

    ( echo "echo foo" ; sleep 5 ; echo "echo bar" ; sleep 5 ; echo "echo baz" ) | zsh -

outputs foo, bar, baz with 5 second intervals in between. Waiting for EOF or next line would not be very logical here, especially since shells may be and sometimes are used in non-interactive mode by the user and not by the script piping to stdin, and this is what special-casing is against (user input is already very special due to zle).