From never@mile.nevermind.kiev.ua  Wed Oct 16 07:17:01 2002
Return-Path: <never@mile.nevermind.kiev.ua>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 31BFE37B401
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 16 Oct 2002 07:17:01 -0700 (PDT)
Received: from mile.nevermind.kiev.ua (office.netstyle.com.ua [213.186.199.26])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7233343EB2
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 16 Oct 2002 07:16:58 -0700 (PDT)
	(envelope-from never@mile.nevermind.kiev.ua)
Received: from mile.nevermind.kiev.ua (never@localhost [127.0.0.1])
	by mile.nevermind.kiev.ua (8.12.6/8.12.6) with ESMTP id g9GEGswX033561
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 16 Oct 2002 17:16:55 +0300 (EEST)
	(envelope-from never@mile.nevermind.kiev.ua)
Received: (from never@localhost)
	by mile.nevermind.kiev.ua (8.12.6/8.12.6/Submit) id g9GEGsLm033560;
	Wed, 16 Oct 2002 17:16:54 +0300 (EEST)
Message-Id: <200210161416.g9GEGsLm033560@mile.nevermind.kiev.ua>
Date: Wed, 16 Oct 2002 17:16:54 +0300 (EEST)
From: Alexandr Kovalenko <never@nevermind.kiev.ua>
Reply-To: Alexandr Kovalenko <never@nevermind.kiev.ua>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: /bin/sh does not support 'command1 & && command2' syntax, which is REQUIRED by POSIX
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         44142
>Category:       bin
>Synopsis:       /bin/sh does not support 'command1 & && command2' syntax, which is REQUIRED by POSIX
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Oct 16 07:20:01 PDT 2002
>Closed-Date:    Wed Oct 16 08:57:03 PDT 2002
>Last-Modified:  Wed Oct 16 09:30:02 PDT 2002
>Originator:     Alexandr Kovalenko
>Release:        FreeBSD 4.7-RELEASE i386
>Organization:
Net.Style
>Environment:
System: FreeBSD xxx.yyy.com 4.7-RELEASE FreeBSD 4.7-RELEASE #1: Tue Oct 15 17:18:12 EEST 2002     root@xxx.yyy.com:/usr/obj/usr/src/sys/kurush  i386

>Description:
/bin/sh does not support 'command1 & && command2' syntax, which is REQUIRED by POSIX:
According to:
http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html#tag_02
(which is part of SUSv3 specification):

1. Shell command definition
--- cut ---
Shell Commands

This section describes the basic structure of shell commands. The following
command descriptions each describe a format of the command that is only used to
aid the reader in recognizing the command type, and does not formally represent
the syntax. Each description discusses the semantics of the command; for a
formal definition of the command language, consult Shell Grammar .

A command is one of the following:
	Simple command (see Simple Commands )
	Pipeline (see Pipelines )
	List compound-list (see Lists )
	Compound command (see Compound Commands )
	Function definition (see Function Definition Command )
--- cut ---

2. Asynchronous list definition
--- cut ---
Asynchronous Lists

If a command is terminated by the control operator ampersand ( '&' ), the shell
shall execute the command asynchronously in a subshell. This means that the
shell shall not wait for the command to finish before executing the next
command.

The format for running a command in the background is:

command1 & [command2 & ... ]

The standard input for an asynchronous list, before any explicit redirections
are performed, shall be considered to be assigned to a file that has the same
properties as /dev/null. If it is an interactive shell, this need not happen.
In all cases, explicit redirection of standard input shall override this
activity.

When an element of an asynchronous list (the portion of the list ended by an
ampersand, such as command1, above) is started by the shell, the process ID of
the last command in the asynchronous list element shall become known in the
current shell execution environment; see Shell Execution Environment . This
process ID shall remain known until:

   1. The command terminates and the application waits for the process ID.
   2. Another asynchronous list invoked before "$!" (corresponding to the
	  previous asynchronous list) is expanded in the current execution
      environment.

The implementation need not retain more than the {CHILD_MAX} most recent
entries in its list of known process IDs in the current shell execution
environment.

Exit Status

The exit status of an asynchronous list shall be zero.
--- cut ---

3. AND list definition
--- cut ---
AND Lists

The control operator "&&" denotes an AND list. The format shall be:

command1 [ && command2] ...

First command1 shall be executed. If its exit status is zero, command2 shall be
executed, and so on, until a command has a non-zero exit status or there are no
more commands left to execute. The commands are expanded only if they are
executed.

Exit Status

The exit status of an AND list shall be the exit status of the last command
that is executed in the list.
--- cut ---

Using those definitions:

	a) 'command1 &', which is correct asynchronous list is command;
	b) 'command2', which is simple command is command;
	c) let 'command1 &' will be 'k1', look at a) for 'why?';
	d) let 'command2' will be 'k2', look at command definition for 'why?';
	e) 'k1 && k2' is command according to command definition and will be
       correct AND list;
	f) as far as 'k1 && k2' is correct (and REQUIRED to support) construct by
	   SUSv3, and 'k1' == 'command1 &' and 'k2' == 'command2', 'command1 & &&
       command2' is correct (and REQUIRED to support) syntax according to SUSv3.

Resume: we need to backout changes to /bin/sh, which prevents 'command1 & &&
command2' from being evaluated correctly.

>How-To-Repeat:
Try to run 'ls & && ls' on 4.7-RELEASE and -STABLE.
>Fix:

Backout relevant changes.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: wollman 
State-Changed-When: Wed Oct 16 08:55:59 PDT 2002 
State-Changed-Why:  
The Standard is quite clear and does not support submitter's desired 
interpretation of the shell grammar. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=44142 

From: Garrett Wollman <wollman@lcs.mit.edu>
To: Alexandr Kovalenko <never@nevermind.kiev.ua>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: bin/44142: /bin/sh does not support 'command1 & && command2' syntax, which is REQUIRED by POSIX
Date: Wed, 16 Oct 2002 11:55:42 -0400 (EDT)

 <<On Wed, 16 Oct 2002 17:16:54 +0300 (EEST), Alexandr Kovalenko <never@nevermind.kiev.ua> said:
 
 > /bin/sh does not support 'command1 & && command2' syntax, which is REQUIRED by POSIX:
 
 Your interpretation is erroneous.  The grammar takes precedence over
 the textual description of the syntax, and the grammar is quite clear:
 
 complete_command	: list separator
 			| list
 			;
 list			: list separator_op and_or
 			|		    and_or
 			;
 and_or			:			    pipeline
 			| and_or AND_IF   linebreak pipeline
 			| and_or OR_IF    linebreak pipeline
 			;
 
 The pseudo-syntax `command1 &' can only be resolved by the `list'
 production in the grammar.   The `&&' and `||' operators take
 pipelines, and not lists, as operands.  See XCU6 page 58.
 
 -GAWollman
 

From: Alexandr Kovalenko <never@nevermind.kiev.ua>
To: Garrett Wollman <wollman@lcs.mit.edu>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/44142: /bin/sh does not support 'command1 & && command2' syntax, which is REQUIRED by POSIX
Date: Wed, 16 Oct 2002 19:26:12 +0300

 Hello, Garrett Wollman!
 
 On Wed, Oct 16, 2002 at 11:55:42AM -0400, you wrote:
 
 > > /bin/sh does not support 'command1 & && command2' syntax, which is REQUIRED by POSIX:
 > 
 > Your interpretation is erroneous.  The grammar takes precedence over
 > the textual description of the syntax, and the grammar is quite clear:
 > 
 > complete_command	: list separator
 > 			| list
 > 			;
 > list			: list separator_op and_or
 > 			|		    and_or
 > 			;
 > and_or			:			    pipeline
 > 			| and_or AND_IF   linebreak pipeline
 > 			| and_or OR_IF    linebreak pipeline
 > 			;
 As we can see from Grammar:
 
 pipeline         :      pipe_sequence
                  | Bang pipe_sequence
                  ;
 pipe_sequence    :                             command
                  | pipe_sequence '|' linebreak command
                  ;
 So, we can parse 'command1 & && command2' in this way:
 
 'command1 & && command2' : and_or(complete_command(list('command1') separator(' ')) separator_op('&') AND_IF pipeline('command2'))
 
 > The pseudo-syntax `command1 &' can only be resolved by the `list'
 > production in the grammar.   The `&&' and `||' operators take
 > pipelines, and not lists, as operands.  See XCU6 page 58.
 Yes. It is correct. Sorry for false alert.
 
 -- 
 NEVE-RIPE
 Ukrainian FreeBSD User Group
 http://uafug.org.ua/
>Unformatted:
