bet@ORION.MC.DUKE.EDU (Bennett Todd) (07/19/89)
Bash 1.01, SunOS 3.5, gcc 1.34 -traditional -g The following script (which I have in /usr/local/bin/lpr) started core dumping on me when I switched my login shell to bash. >tmp=/tmp/lpr.$$ >trap "rm -f $tmp; exit 0" 0 >trap "rm -f $tmp; exit 1" 1 2 3 >cat $* >$tmp >if test "`hostname`" = "blinken" >then > (stty new litout; cat <$tmp; echo -n ' ') >/dev/ttya & >else > rsh blinken $0 <$tmp & >fi > >sleep 1 >rm -f $tmp As best I can tell, the core dump is coming from the child shell spawned on the local machine to process the script; it appears in the current directory rather than in home (where I would expect it if it were the rsh-ed bash). It isn't the parent shell since I don't get logged off:-). Here's what gdb says: Script started on Tue Jul 18 15:20:30 1989 bent[1] gdb `which bash` core GDB 3.1, Copyright (C) 1988 Free Software Foundation, Inc. There is ABSOLUTELY NO WARRANTY for GDB; type "info warranty" for details. GDB is free software and you are welcome to distribute copies of it under certain conditions; type "info copying" to see the conditions. Reading symbol data from /usr/local/bin/bash...done. Core file is from "bash". Program terminated with signal 11, Segmentation fault. Warning: core file does not match specified executable file. Type "help" for a list of commands. (gdb) where #0 0x2afe in reader_loop () (shell.c line 599) #1 0x40028 in interactive () (gdb) quit bent[2] script done on Tue Jul 18 15:49:28 1989 599 in shell.c is the close curly brace at the end of reader_loop; that doesn't make sense to me, unless the return stack is getting trashed somehow. Why did gdb say "Warning: core file does not match specified executable file."? I'm confused. Needless to say I fixed the shell script by prepending #!/bin/sh; however, since I hope eventually to "mv /bin/sh /bin/sh.old;mv /usr/local/bin/bash /bin/sh" I don't like having to do that. -Bennett bet@orion.mc.duke.edu