Date: Sat, 19 Mar 2011 09:44:57 -0700 From: Devin Teske <dteske@vicor.com> To: Maxim Khitrov <max@mxcrypt.com> Cc: FreeBSD <freebsd-questions@freebsd.org>, Andres Perera <andres.p@zoho.com>, 839273@gmail.com Subject: Re: Shell script termination with exit function in backquotes Message-ID: <EFA32C5B-1892-41C3-B34B-F96E75CA72CA@vicor.com> In-Reply-To: <AANLkTimWxiRQNG3Um__kY-6%2BQ59g5yZT-Kt0qLAqTWOO@mail.gmail.com> References: <AANLkTi=-CFmxRicGcosvzhBbM3DMjbWwQNirMrJ1_KP=@mail.gmail.com> <759A467E-407A-4DB8-9756-08011B5405F0@vicor.com> <AANLkTi=CXLFUBhnY1LuhkeUiGHHGZ43yd%2BMYE9L50_O4@mail.gmail.com> <AANLkTimrnV2rJLyc3M4e3gGy_GUDLXp128f6n8svM3_g@mail.gmail.com> <AANLkTim0GvnAyK3%2B=Bd1Sr=maz0B3Ybgve_c6FKWwfNs@mail.gmail.com> <AANLkTimWxiRQNG3Um__kY-6%2BQ59g5yZT-Kt0qLAqTWOO@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 19, 2011, at 9:15 AM, Maxim Khitrov wrote: > On Mon, Mar 14, 2011 at 6:40 PM, Andres Perera <andres.p@zoho.com> = wrote: >> On Mon, Mar 14, 2011 at 7:46 AM, Maxim Khitrov <max@mxcrypt.com> = wrote: >>> On Mon, Mar 14, 2011 at 3:16 AM, Andres Perera <andres.p@zoho.com> = wrote: >>>> On Sun, Mar 13, 2011 at 9:49 PM, Devin Teske <dteske@vicor.com> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EFA32C5B-1892-41C3-B34B-F96E75CA72CA>