Bourne-Shell and fork() (was Re: K-shell variables & Do-loops)

[Maarten Litmaath]

In article <642 at mwtech.UUCP>,
	martin at mwtech.UUCP (Martin Weitzel) writes:
)...
){ cd somewhere; morestuff;} > whatever # sh now forks!! working directory
)morecommands                # doesn't change for process executing morecommands

Too bad... :-(
Now we need something gross like the following to redirect the output to
another file temporarily:

	exec 3>&1 > file	# remember the original stdout in file
				# descriptor 3, connect stdout to `file'
	some_stuff
	exec 1>&3 3>&-		# reconnect stdout to the original file,
				# close fd 3

)...
)v="initial value"
)v="new value" cmd # v is set to "new value" only in the environment of cmd
)nextcommand $v	  # and $v expands to "initial value" here
)
)This is well-known behaviour. But what, if cmd is executed internally?
)I think you guessed it -- now $v expands to "new value" when executing
)nextcommand.  The following fragment of a script makes use of this:
)
)x=external
)x=internal pwd >/dev/null
)echo "pwd is an $x command in this version of the shell"

This behavior is RIDICULOUS!  A DISGUSTING BUG!
When a `normal' command is made into a built-in, redirection mustn't change
its behavior.  Likewise it shouldn't make any difference if a command is a
function or an executable.

)...
)BTW: I would not be surprised, if the behavior of {}-command grouping
)and loops with redirection will change in the future ... so don't
)depend on it.

If the behavior of {}-grouping and loops with redirection were to change,
it would break some scripts.  Considering the gain in elegance I wouldn't
object though.
--
  "Ever since the discovery of domain addresses in the French cave paintings
  [...]"  (Richard Sexton)      |  maart at cs.vu.nl,  uunet!mcsun!botter!maart