From owner-freebsd-questions@FreeBSD.ORG Sat Mar 19 16:45:00 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0C80106567C for ; Sat, 19 Mar 2011 16:45:00 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id C97BA8FC14 for ; Sat, 19 Mar 2011 16:45:00 +0000 (UTC) Received: from [173.241.25.35] (port=50163 helo=[10.0.0.104]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74) (envelope-from ) id 1Q0zH2-0005Ro-L7; Sat, 19 Mar 2011 09:45:10 -0700 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Devin Teske In-Reply-To: Date: Sat, 19 Mar 2011 09:44:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <759A467E-407A-4DB8-9756-08011B5405F0@vicor.com> To: Maxim Khitrov X-Mailer: Apple Mail (2.1082) X-Scan-Signature: b33a05b2664869ea37197335591d72c9 X-Scan-Host: postoffice.vicor.com Cc: FreeBSD , Andres Perera , 839273@gmail.com Subject: Re: Shell script termination with exit function in backquotes X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 16:45:01 -0000 On Mar 19, 2011, at 9:15 AM, Maxim Khitrov wrote: > On Mon, Mar 14, 2011 at 6:40 PM, Andres Perera = wrote: >> On Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov = wrote: >>> On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera = wrote: >>>> On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske = wrote: >>>>> If you make the changes that I've suggested, you'll have = consistent execution. The reason you're having inconsistent behavior is = because Linux has /bin/sh symbolically linked to /bin/bash while FreeBSD = has a more traditional shell (we'll call it bourne shell "plus"). >>>>=20 >>>> that is misleading because command substitutions have traditionally >>>> invoked subshells, and freebsd sh(1)/ash is an exception, not the = norm >>>>=20 >>>> in this case, ksh and bash deviates are clearly closer to standard >>>> bourne behaviour >>>>=20 >>>=20 >>> Thanks for that explanation. I can understand the benefits of >>> optimizing away subshell execution, but that can clearly lead to >>> unexpected behavior. Is there some documentation on when this >>> optimization is utilized (i.e. the command executed without a >>> subshell)? Would I be correct in assuming that it is only restricted >>> to built-in commands that are known not to produce any output, such = as >>> 'exit'? >>=20 >> i would check the source, autoconf docs, and = http://www.in-ulm.de/~mascheck/ >>=20 >> netbsd has been patched to fix `exit 1`, according to the last site >=20 > Here's another, but related, problem that I just ran into. The man = page reads: >=20 > Commands may be grouped by writing either > (list) > or > { list; } > The first form executes the commands in a subshell. Note that = built-in > commands thus executed do not affect the current shell... >=20 > Here's my script: >=20 > ---- > #!/bin/sh >=20 > { A=3D1; }; echo $A > echo | { B=3D2; }; echo $B > { C=3D3; } > /dev/null; echo $C > ---- >=20 > And here's the output: >=20 > ---- > 1 >=20 > 3 > ---- >=20 > Where did the '2' go? You're learning that there are deviations to the rule as-mentioned in = the man-page. At least two variations to the rule that { ... } is a block of commands = executed in the current shell are: 1. When the block appears as a function and 2. When the block appears on the right-hand side of a pipe (with or = without following pipe(s)). The reason for these deviations is quite simple in-fact... The shell needs to create a new set of stdin/stdout file-descriptors for = the block of commands that you've created, and executing said commands = within a sub-shell achieves that. I hope that helps explain. -- Devin > Again, I have to assume that when stdin is piped > to a group of commands, those commands are executed in a subshell > despite curly braces. But where is this behavior documented? It seems > that there are a lot of corner cases that can only be understood if > you are familiar with the shell implementation. Documentation can > certainly be improved in places. >=20 > - Max