Date: Wed, 16 Oct 2002 17:16:54 +0300 (EEST) From: Alexandr Kovalenko <never@nevermind.kiev.ua> To: FreeBSD-gnats-submit@FreeBSD.org Subject: bin/44142: /bin/sh does not support 'command1 & && command2' syntax, which is REQUIRED by POSIX Message-ID: <200210161416.g9GEGsLm033560@mile.nevermind.kiev.ua>
next in thread | raw e-mail | index | archive | help
>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: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 16 07:20:01 PDT 2002 >Closed-Date: >Last-Modified: >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: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210161416.g9GEGsLm033560>