erskine@force10.UUCP (12/03/87)
][b
---------- Files required to reproduce the problem:
$ cat init.dom
echo hello
. ./init.std
echo goodbye
exit 0
$ cat init.std
std_perms()
{
cat << --EOF--
--EOF--
}
$ cat newdom
. ./init.std
./init.dom
---------- To reproduce the problem:
Create the previous files in one directory, make them executable, and
from the Bourne Shell (/bin/sh) type
$ ./newdom
---------- I think the output should be:
$ ./newdom
hello
goodbye
$
---------- but on my system I get:
$
hello
./init.dom: shell memory fault$
---------- Commentary:
I'm running SCO Xenix System V version 2.2.1, and have found the
bug demonstrated by the accompanying files. By moving these files to
subdirectories, and making corresponding changes in the scripts, /bin/sh
goes into a tight CPU loop, disregarding signals.
The problem is that shell functions, unlike variables, get passed on
to child shell scripts. The redefinition of the shell function seems to
cause a big problem for sh if the function makes use of the << operator.
(But only if the function was inherited). Should the function definition
actually be inherited by child scripts? If yes, should shell variables also?
To check to see, add the command 'set' as the first line in init.dom.
If the functions are inherited, the definition of std_perms will be printed
along with the environment.
I phoned SCO who agreed that it is a bug, but who suggested that it
might be appropriate to forbid this usage (redefinition of a shell
function). I certainly haven't used many interpreters that didn't allow
redefinition of functions.
Most importantly, WHAT DOES YOUR /bin/sh DO? Please post to the net,
especially if yours doesn't inherit shell functions. If you don't HAVE
shell functions at all, LUCKY YOU, you don't have the bug! :-)
Neil
||!][b
---------
Neil S. Erskine MT&T - (902) 453-4915 x340
AP Computers USENET { garfield, watmath, ihnp4!utzoo!utai,
3845 Dutch Village Rd. uunet } !dalcs!force10!erskine
Halifax, N.S. B3L-4H9