From owner-freebsd-bugs Sun Jan 14 8: 0:21 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 80DDD37B400 for ; Sun, 14 Jan 2001 08:00:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f0EG04f47092; Sun, 14 Jan 2001 08:00:04 -0800 (PST) (envelope-from gnats) Date: Sun, 14 Jan 2001 08:00:04 -0800 (PST) Message-Id: <200101141600.f0EG04f47092@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "R. Imura" Subject: Re: bin/24228: /bin/sh problem : variable after pipeline won't be set Reply-To: "R. Imura" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/24228; it has been noted by GNATS. From: "R. Imura" To: Peter Pentchev Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/24228: /bin/sh problem : variable after pipeline won't be set Date: Mon, 15 Jan 2001 00:49:26 +0900 On Sun, Jan 14, 2001 at 12:47:51PM +0200, Peter Pentchev wrote: > AFAIK, yes, this is expected sh(1) behavior. From the manpage: > > Note that unlike some other shells, sh executes each process in the > pipeline as a child of the sh process. Shell builtin commands are the > exception to this rule. They are executed in the current shell, although > they do not affect its environment when used in pipelines. > > That is, sh(1) forks a subshell for each subsequent command/construct > in the pipe, and variable assignments within a construct are only valid > for the subshell that construct is executing in, and not back-propagated > to the main shell. > > Thus, in your example, 'variable' would only be set to 'bar' for > the subshell executing the while loop. See below for a suggestion > for a workaround. Thanks very much for your explanation. I got it. :) So, please close this PR. - R. Imura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message